12 ms·

> Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so mu

• optimuspaul 9y ago
  Totally disagree with you.... it's funny though that I read LOC as "level of complexity" not "lines of code". I've been writing code for 30 years and I think it's jarring when the braces are on the next line, so much easier for me to parse that when it's on the same line. But everyone is entitled to their own opinion.
  • alunchbox 9y ago
    python fans are going like "what are braces?"
    • kabdib 9y ago
      That's fine -- the Python folks have their own share of religious wars (starting with: tabs, or spaces?) :-)
      • TomMarius 9y ago
        Tabs, everyone can configure them however they want. :-)
        • RobertRoberts 9y ago
          I hate being able to configure stuff, I want other people to boss me around from anywhere in the world! Their opinion matters on my computer!
        • tabbspace 9y ago
          Until you need spacing that isn’t a multiple of your tab width then you’re screwed.
          • YSFEJ4SWJUVU6 9y ago
            Why would you ever half-indent a block? For alignment you should of course use spaces (for whole alignment, not just the end, to be very clear).
            • tabbspace 9y ago
              Lining up arguments across multiple lines sometimes involves non-multiples of tabs.
      • gambiting 9y ago
        As a C++ programmer I can assure you, I know plenty of individuals with very strong opinions on tabs vs spaces debate.
        • drawkbox 9y ago
          And spaces sub factions/opinions on 2 vs 4 spaces. The correct answer is whatever the project is already using, unless it is new and then you luckily get to choose.
      • tom_mellior 9y ago
        Do they? All the Python folks I've ever seen express an opinion on style have said "follow PEP 8". Unsurprisingly, PEP 8 does have a rule for tabs vs. spaces: https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces (spaces, of course)
        • jwilk 9y ago
          As a data point, I don't follow (all of) PEP-8. But tabs vs. spaces is indeed a bad analogy, because of course it's 4 spaces. ;-P pycodestyle, the Python style checker, has a few checks disabled by default (because there's no consensus they're good ideas), and even some mutually exclusive ones: https://pycodestyle.readthedocs.io/en/latest/intro.html#error-codes https://pycodestyle.readthedocs.io/en/latest/intro.html#erro...
        • sireat 9y ago
          I love Python but as a long time C programmer I can't understand the preference for spaces in PEP 8. Tabs are semantic and only take one key press for movement back and forth and to delete. If you see 1 tab you know it meant one indentation level. With spaces you have to think. Plus with spaces you are stuck with 2/4/8 spacing(unless you reformat), with tabs you can configure your editor to your preferences.
          • slaman 9y ago
            > with tabs you can configure your editor to your preferences. Configure 1 tab to be 4 spaces. Sometimes it's easier to go with the flow. I like tabs for the reasons you mentioned, but fixed-width spaces are a bit better for some reasons too. IDE's can do the heavy lifting of re-formatting indentation levels and converting tabs to spaces for me, and it means if I cat a file on a remote server regardless of the bash tab width settings or if I'm in your code or the stdlib it will all make sense.
          • e12e 9y ago
            Tabs are semantic. But, when you start down that route, why not dictate record-separotor as replacement for closing brace/block etc?
      • bunderbunder 9y ago
        These religious wars can largely be swept away with one simple, practical question: What is going to result in less noise in pull requests and the commit history, given that nowadays everyone uses a different editor with different configuration defaults, and is going to result in less time in pull requests squabbling over these kinds of formatting issues, given that nowadays everyone uses a different editor with different configuration defaults? Tabs vs. Spaces has a fairly good answer that flows out of this way of looking at things. There is a counter-argument to that answer, but it is invalidated if you move toward conventions for argument lists and chained method calls that are also designed to limit noise in the source control system. IMO, the argument about bracing also has a practical, non-religious answer once you start looking at your coding conventions this way.
      • jjgreen 9y ago
        Both!
      • kevin_thibedeau 9y ago
        The war is over. Py3 doesn't allow mixed spaces and tabs in the same file. You choose your side and never get to skirmish with the other one.
    • zerostar07 9y ago
      but biased fans of both would argue that opening and closing a block in the same indent level (allman-style) is closer to python.
    • lisper 9y ago
      The irony is that Python actually has open-braces, but they're spelled ":" instead of "{". And the syntax effectively enforces K&R style. When I write Python I end every block with a "pass" statement so that emacs can auto-indent my code properly. The "pass" statement thus effectively becomes a close-brace. It drives Pythonistas into conniptions, but I never have to worry about reverse-engineering a block of code to figure out how to restore the proper block boundaries after a cut-and-paste has screwed up the indentation.
      • deleted 9y ago
        [deleted]
      • kamaal 9y ago
        That's the bad part of not having braces. If boundaries exist they need to be clear. One shouldn't have to count the tabs that make up the level of indentation. Its already a challenge reading code. Counting invisible tabs makes it even worse.
        • lisper 9y ago
          Well, you don't have to literally count them, you use the spatial reasoning hardware built in to your retina and visual cortex to just see that this bit of code is further over to the right than that bit of code. But of course that only works for pieces of code that are small enough to fit in your field of view.
          • p1esk 9y ago
            All code pieces should be small enough to fit in your field of view :)
            • lisper 9y ago
              Try to tell that to my current client :-(
        • dorgo 9y ago
    • sethgecko 9y ago
      >>> from __future__ import braces SyntaxError: not a chance
    • laythea 9y ago
      Tell them braces are visual indicators of blocks of logic, enabling reasoning more easily on a multi-statement level.
      • threatofrain 9y ago
        Lambdas shouldn't be more than one line anyway.
  • kstenerud 9y ago
    I've done a number of informal tests on friends and family over the years regarding brace placement, and it's always been the same: For someone with NO experience programming (i.e. looking at what to them seems like a bunch of gobbletygoop - and what's a "text editor"?), adjacent braces make it appear more readable than same-line braces. It's only people who cut their teeth on adjacent bracing that find it more readable.
    • falcolas 9y ago
      Why optimize for the lowest common denominator? I've seen both, and the reduction in vertical whitespace matters more to me than the readability to an untrained individual.
      • RobertRoberts 9y ago
        >Why optimize for the lowest common denominator? You seem to be erroneously equating a coincidence with a preference.
      • hailk 9y ago
        I'll be flipping the point around by saying that if you are concerned about vertical whitespace reduction, you should probably look at the granularity of your files (debatable based on programming environment). Also we could be catering to the lowest common denominator by worrying about people with untrained symmetric sensibility.
      • z3t4 9y ago
        Tip: Tilt your wide screen so you get more vertical real estate.
    • ainiriand 9y ago
      'I've done a number of informal tests on friends and family' You should have a pretty cool family!
  • psyc 9y ago
    I've also been coding 30 years. I have to use same line at work, and I use next line in my (very large) side projects. Honestly, I don't know what the difference is.
    • JackFr 9y ago
      > (very large) side projects How big once you remove all the extra newlines?
      • ccvannorman 9y ago
        LOL. This is the part of the Silicon Valley episode-bar-scene where the fight breaks out. Thank god OC didn't mention "Just like you move from tabs to spaces."
        • YSFEJ4SWJUVU6 9y ago
          Well, he shouldn't have, considering it's the other way around.. :-)
        • torstenvl 9y ago
          I never understood this part of the show. I'd think that the genius inventor of a breakthrough compression algorithm whose WHOLE POINT was high quality lossless compression would prefer spaces over tabs. After all, the compression algorithm can deal with it... without the issues that result from embedding hard tabs in a source file.
  • ivanhoe 9y ago
    In last 20+ years I've changed the coding style many times, usually to fit the current team style. And in my experience it takes a few weeks for the brain to rewire to the new style. First you hate it, and then you get used to it, and then you're like: wow it's great. Then you switch the standards for a new project and again, the same steps. It's just a matter of habit...
    • josephv 9y ago
      Pragmatic programming has lost. If you aren't a zealot about being pedantic, just move into the old-folks home.
      • ravitation 9y ago
        I enjoy zealous pedantry. I have strong personal opinions about something that I do a lot (especially the pedantic parts), but most of it is relatively lighthearted.
      • Zyst 9y ago
        Not at all, I'd argue this whole Tabs/Spaces, bracket placement, single/double quote discussion should be getting killed by code formatters. At the end of the day you can do whatever you want with the code you're writing, and some pre-commit hook can run go fmt/prettier/whatever and then it'll all get standardized. I've become a very heavy proponent of code formatters (I added prettier to the entire team) and I truly believe that talk about code formatting will never really die off, but at the end of the day you can do whatever you want on your side but still have a standardized looking codebase, and that feels extremely liberating to me. As a PS: If you are a diehard tab proponent/different bracket placement/whatever but your team formatter configuration uses spaces instead then you can also use code formatters to do spaces -> tabs locally, say, on file open. Once you commit your file your precommit falls back to the team configuration, which removes your tabs. Everyone is happy.
        • cortesoft 9y ago
          I think the person you are responding to was being sarcastic...
  • brann0 9y ago
    I always adapt to the style used in the project I land. I can understand people liking one over another but to reach holy wars levels of disagreement about this kind of subject is something I don't get. Same goes to spaces vs braces, editor wars, etc. Downside: my projects are usually a bit of a mess with mixed indentation styles :D
  • DanHulton 9y ago
    I've actually evolved a hybrid style in my personal projects - next line for functions/classes, same line for blocks. To me, it looks weird when functions don't have that extra line of space to set off their definition, but if/while/whatever aren't special enough to need that call out. That said, the most important factor is simple consistency. In my person projects, I have the hybrid style. At work, I use same-line-only. If I'm on a project that has next-line, we all use next-line.
    • nitrogen 9y ago
      I think the Linux kernel style is similar. That was the first coding standard I somewhat adopted, but naturally have adapted to many others on different teams over time.
      • erik_seaberg 9y ago
        I think this style dates back to K&R C where you (maybe) declared argument types after the parens. int max(a, b) double a, b; { return a > b ? a : b; }
  • Bombthecat 9y ago
    I remember in my programming classes at school my teacher was always like: guys!there is space on the right! Use it! PS: he coded at Hercules the graphic cards back in the day before he got into teaching.
    • z3t4 9y ago
      What is "Hercules the graphic cards" (I only found GPU's when trying Google)
      • mr_toad 9y ago
        The Graphics Card (HGC) was essentially an MDA-compatible monochrome card with an added all-points-addressable graphics mode. https://en.wikipedia.org/wiki/Hercules_Graphics_Card https://en.wikipedia.org/wiki/Hercules_Graphics_Card
      • deleted 9y ago
        [deleted]
  • boomlinde 9y ago
    The level of complexity obviously doesn't change with a line break
• redleggedfrog 9y ago
  Yeah, I agree with the list above except for that one. It always bugged me that idiomatic Javascript was like this. I guess Javascript just bugs me in general, though, too.
• youngtaff 9y ago
  I'm with you on Allman style braces, prefer it and find them much easier to read. As everyone else seems to use K&R I've just had a adapt over time :-(
  • drawkbox 9y ago
    A pro maintains consistency though so that is good. I like One True Brace Style (1TBS) with an uncuddled 'else', which has else/else if on new-line with the break before it (similar to Stroustrup K&R without any same line properties, one thing per line, no bracket-less statements) and setup the standard that way if I am designing it, but do Allman or whatever variant the codebase uses if it already exists.
    • CodeWriter23 9y ago
      I’m with you on this, and all that other stuff you said. But really, on the topic of braces, brackets and parentheses, any decent editor will highlight the matching brace for you.
  • bunderbunder 9y ago
    What's interesting to me is, anecdotally, the people I know who are the biggest K&R haters are people who started with K&R, then had to switch to Allman for a significant length of time, and then had to switch back to K&R.
    • drewmate 9y ago
      That probably tells you more about the haters than the brace style. That was my career path, and while I've gotten used to reading Allman braces, I've heavily relied on tooling (especially Visual Studio) to auto-format my K&R (or 1TBS) braces for whatever project I'm in. Same thing with tabs/spaces. There are lots of sane ways to read code, but consistency is key. It's hard to change muscle memory in how I type, though, so I think auto format is the way to go.
• princekolt 9y ago
  I agree. This is especially good when you have long method names and the method declaration might need more than one line. Having the opening brace on a new line clearly separates where the function/method declaration ends and the body begins.
• Traubenfuchs 9y ago
  As someone who started out with C# and learned Java later, let me tell you: This is nonsense. You can get used to both easily, but only one of them saves space.
• melling 9y ago
  The One True Brace Style: https://softwareengineering.stackexchange.com/questions/99543/what-is-the-difference-between-kr-and-one-true-brace-style-1tbs-styles https://softwareengineering.stackexchange.com/questions/9954... The name tells you that it won.
  • JoeAltmaier 9y ago
    That link's favorite response actually refutes that brace style matters at all. No correlation with bug frequency detectable. So its all religion.
    • RobertRoberts 9y ago
      It's not "religion" if there's a technical reason to choose one method over another. A later comment on the SO post described how K&R can have maintenance costs because when moving things around it's more difficult to tell where a statement ends, and can accidentally cause side effects.
      • JoeAltmaier 9y ago
        Not reflected in the bug statistics, according to the post. So if the effects exists, its negligible.
        • RobertRoberts 9y ago
          >So if the effects exists, its negligible. The only thing being considered was "bugs in the final code", not "time and effort in maintenance."
    • ergothus 9y ago
      I wish this sentiment were expressed more often but also expressed less judgmentally and given more depth than sometimes occurs.. To say it is religion isn't to say "your preference is dumb". In my own code preferences I try to maintain a split between "have a reason I have confidence in" and "personal preference". And "easier to read" is almost always in the latter. (If you can say WHY, that is the actual reason, but your actual reason still has to be provable.) Given the difficulty of finding good research and the inherent difficulty of the research (if familiarity is a big component to preference, and a proven ability to mentally parse code required to judge, then good luck running a control group) I have a lot of items I have confidence in being provable without having actual proof, but the lengthy preference list also means I'm willing to accept that each of those can switch columns. Way too many of our "easier to read" defenses are really "it is easier to read because I'm familiar with it. I personally think camelCase is terrible - language has spaces for reasons! - but there is no denying that it is very common and that the vast majority of coders learned it first, an unfortunate self perpetuating cycle. Nonetheless, shown research that said I was wrong (assuming said research had taken familiarity into account) I would change my stance rather than dig in my heels...even if that change were to only add "but that's just me" to the end of it.
• JKCalhoun 9y ago
  I agree. I'm not looking to increase code density. I leave empty lines between logical sections within functions to allow the code "breathe". It helps me parse my own code.
• zerostar07 9y ago
  for a vi user, visually selecting a block to its matching end for cutting/pasting is the equivalent of coding photoshop
  • khedoros1 9y ago
    v%y works well enough, seems like.
• zanny 9y ago
  I used Python enough that braces are completely meaningless to me in languages with them (ie, everyone else). Indentation is my mental delineation of code blocks. I just have to write these {} things all over the place because every other language is a gramatically bloated mess. The advent of automatic code formatting (and Python pioneered this in many ways with pep8, but even huge C++ projects are realizing the value in clang-format, clazy, etc) put the nail in the coffin of arguments against whitespace blocking. You can have an enforced uniform style throughout a project now, with no ambiguity, and in such contexts using whitespace as a block delimiter also has no ambiguity. It just takes advantage of formatting already being done to avoid redundant glyph use.
  • btilly 9y ago
    Let's see. The Unix indent utility was what, mid-1980s? GNU indent came out in 1989. Python was released in the mid-1980s. PEP-8 was released in 2001. Yup, Python clearly pioneered automatic code formatting. Nobody had done it before them...
    • Someone 9y ago
      Lisp pretty printing was available in February 1973 (http://www.softwarepreservation.org/projects/LISP/MIT/AIM-279-Goldstein-Pretty_Printing.pdf http://www.softwarepreservation.org/projects/LISP/MIT/AIM-27...). That document states Bill Gosper wrote one of the first pretty printers, but doesn’t give a date for it. I would think it is much older, as writing a simple lisp pretty-printer is easy and reading lisp without autoformatting is “less than ideal”.
  • sedachv 9y ago
    > I just have to write these {} things all over the place because every other language is a gramatically bloated mess. In what way are context-free languages "a grammatically bloated mess?" Whitespace delimited languages like Python have context-sensitive grammars. Now that is a mess.
    • WorldMaker 9y ago
• hailk 9y ago
  I see it the same way. It offers symmetry. The method name can be as long or short. At least the start of the code block and the end is easily visible since the indentation level remains same. Gives a sense of Python readability.
  • lisper 9y ago
    Huh? My emacs auto-indents both styles in exactly the same way: void foo() { code...; } void foo() { code...; }
    • hailk 9y ago
      The start of the code block is signified by the opening brace, which starts at the end of the method name in the first case, hence breaking symmetry.
      • lisper 9y ago
        To my eye, the start of the code block is signified by the indentation, i.e.: stuffstuffstuff.... stuffstuffstuff... So I read C and Python (and Lisp) code the same way. A naked open brace looks jarring and ugly to me. It also increases the separation of other related parts of the code, i.e. if (...) { while(...) { do(...) { vs if (...) { while(...) { { do(...) { The latter seems unnecessarily wasteful to me.
        • Merad 9y ago
          K&R isn't that terrible when code is neat and clean, but it starts to have trouble IMO particularly when declarations or conditions wrap to multiple lines. Compare the following examples... I personally have to stop and read the code to find the blocks with K&R braces, vs being able to see them at a glance with Allman. void MyLongMethodName(SomeLongParamType param1, SomeOtherLongParamType param2, YetAnotherLongParamType param3) { if (longContrivedVariableName1 == longContrivedVariableName2 && longContrivedVariableName1 != longContrivedVariableName3) { // do stuff } } void MyLongMethodName(SomeLongParamType param1, SomeOtherLongParamType param2, YetAnotherLongParamType param3) { if (longContrivedVariableName1 == longContrivedVariableName2 && longContrivedVariableName1 != longContrivedVariableName3) { // do stuff } }
• reaperducer 9y ago
  I agree with you 100%. It's all about being able to skim through code to find what you want and understand structure quickly. Allman is great for this. Though I'm a Whitesmiths guy, myself. Still, same idea. /36 years of commercial coding here.
• scythe 9y ago
  I don't work on an 80/24 terminal either, but I find that if there's too much text on the screen at a time, my eyes glaze over and don't read it all. So I work with larger fonts and use a terser style with a 40-line rule for functions that aren't switch statements.
• tytytytytytytyt 9y ago
  I agree! The secret to code readability isn't squeezing out all whitespace, vertical or horizontal.
• icedchai 9y ago
  Ok. I've been writing code for 25+ years, and disagree.
• noobermin 9y ago
  I'm often coding on a server that has 4-6 tmux windows along with another terminal window for my local machine. I rarely have only one wall of text open, so I effectively work on mini-terminals often.
• pebcakID10T 9y ago
  NoooOoooooOOOooooOOOooo! I hate Allman braces! My hatred burns with the fire of a thousand suns!
• npsimons 9y ago
  > I'm not working on an 80x24 terminal anymore. Even with 80x24 (don't ask), I fully agree with Allman style braces.