Forgot your password?
typodupeerror
Programming

Does Coding Style Matter? 479

Posted by Soulskill
from the obfuscate-half-and-document-the-other-half dept.
theodp writes "Over at Smashing Magazine, Nicholas C. Zakas makes the case for Why Coding Style Matters. 'Coding style guides are an important part of writing code as a professional,' Zakas concludes. 'Whether you're writing JavaScript or CSS or any other language, deciding how your code should look is an important part of overall code quality. If you don't already have a style guide for your team or project, it's worth the time to start one.' So, how are coding style guidelines working (or not) in your world?"
This discussion has been archived. No new comments can be posted.

Does Coding Style Matter?

Comments Filter:
  • by tirerim (1108567) on Saturday October 27, 2012 @02:48PM (#41790601)
    At my workplace, we just all plug the same code style settings into our IDEs, and everyone's code gets formatted the same way automatically. And yes, it matters: having everyone's code formatted the same way makes it much easier to read.
    • by Anonymous Coward on Saturday October 27, 2012 @02:57PM (#41790667)

      ... and it makes version control diffs shorter and to the point.

      • by sribe (304414) on Saturday October 27, 2012 @03:45PM (#41791099)

        ... and it makes version control diffs shorter and to the point.

        ...and makes global search and replace easier, because you can more often use plain strings, rather than having to construct a regex.

        • by Carewolf (581105) on Saturday October 27, 2012 @06:55PM (#41792443) Homepage

          Coding style has one function and one function only: To keep the Aspergers productive. For normally functioning people, any coding style is as good as any other (in other words anything that isn't a mess), but for Aspergers it is important it is consistant and strictly enforced, otherwise they will complain loudly and start arguing over which style is better (as evidence I present every thread in this story).

          After enforcing strict coding style only one more thing is important to keep the Aspergers productive: Never mention or talk about coding style, and forbid anybody from ever bringing it up. If it is brought up, nothing will get done that day.

    • Intent/line breaks/spacing styles that IDEs can do aren't all that matters though. Simply knowing when to put a blank line in can make all the difference in code readability, but i haven't seen any IDEs smart enough to do that.
      • JetBrains IDEs allow you to do that... I can't imagine that most don't have context rules for adding blank lines.

      • by Derekloffin (741455) on Saturday October 27, 2012 @04:03PM (#41791255)
        I would say, white space rules are definitely important, but not the only style stuff that may be important. Standard variable naming conventions can also greatly help, as can keeping certain common code structure being all done in the same manner. Both of these can make it much easier to find things. The question is where is the point where standard style starts to become more an exercise in keeping to the style rather than getting the work done.
      • Eclipse can do it. You can setup a formatting style and then have it auto-format on save or do it manually with Ctrl+Shift+F.

        Here's a screenshoft [imgur.com].

    • That's along the lines what I was thinking (but not exactly). A good IDE makes coding styles far less important than they use to be. I can load someone's horrendous looking K&R styled code, hit the "reformat" keyboard shortcut, and have readable code as a result.

      Coding style only matters if you're not using a decent IDE.

      • by Dr_Barnowl (709838) on Saturday October 27, 2012 @06:13PM (#41792171)

        .. and then you commit your changes and everyone wants to kill you. You just broke all their patches.

        There have been various proposals for an IDE that stores the sources as a raw format that has no formatting, and you apply the formatting in the view, but they obviously have the disadvantage of not working with a plain text editor, needing a special IDE, probably a special version control system as well.

    • by GeekDork (194851) on Sunday October 28, 2012 @08:00AM (#41795551)

      Code editors (at least most of them) are still stuck in a dark age where everything comes down to hand-crafted ASCII-art, which is complete and utter bullshit. Editors could and should work much closer, if not directly on, the AST of the language in question, and completely abstract away all those pesky details like indenting scopes or formatting comment blocks "properly". That stuff should be left to user preference and style sheets.

      But I guess that would put an immediate end to the religious zeal displayed in tabs-vs-spaces (it's of course ts=8 sw=4 noexpandtab, noobs!), would not mask syntax errors in gobs of meticulously crafted gunk, and take all the "fun" out of programming.

  • Er (Score:3, Insightful)

    by Anonymous Coward on Saturday October 27, 2012 @02:50PM (#41790613)

    Of course coding style fucking matters. Code's generally going to be part of a much larger product that existed long before you joined a company and will continue to exist long after. You don't want the codebase turned into some sort of elaborate puzzle with 200 different methods of laying out code contained within. Uniformity makes maintenance much easier.

    • by udachny (2454394)

      coding style fucking

      - I am aware of different styles of fucking, but this new 'coding style fucking' intrigues me. So you are coding and she is .... trying to distract you from it with your 'fucking implement'? Or is it about maintaining proper indentation at every point of the fucking perimeter? Do expand on this theme.

  • by Onuma (947856) on Saturday October 27, 2012 @02:50PM (#41790623)
    I've always preferred to use tabs over spaces for indentation, 2 breaks in between major sections or functions, and clearly named vars or functions. The kind of code most people can drop into and say "Oh, I see where this is going" and immediately begin to understand and therefore modify.

    I can't stand opening up any type of code, even web pages, and finding ugly difficult-to-follow lines which seemingly make no sense. Then again, it's all a matter of preference and perspective, isn't it?
    • by MrEricSir (398214) on Saturday October 27, 2012 @02:59PM (#41790689) Homepage

      Out of curiosity, why do you prefer tabs? Seems like unless everyone has the same tab size set, it can make the code more difficult to read than spaces.

      Further, most IDEs and text editors have "smart tabs", allowing the simplicity of working with tabs even though you're using spaces.

      • by Anonymous Coward on Saturday October 27, 2012 @03:06PM (#41790767)

        I use tabs because anyone can set the width to whatever they like (2, 4 or 8 spaces usually).

        • by Teckla (630646) on Saturday October 27, 2012 @03:25PM (#41790943)

          I use tabs because anyone can set the width to whatever they like (2, 4 or 8 spaces usually).

          There still exists a lot of tools that assume tab stops are 8, without the ability to change them. Some people use those tools by choice, some people use those tools by mandate.

          • by Anonymous Coward on Saturday October 27, 2012 @03:38PM (#41791033)

            And when you use tabs, it doesn't matter what tab size they assume. That is the point. Proper use of tabs means you use tabs to indent to the block level and spaces for further indentation, like so:

            {
            <-tab->a = long expression
            <-tab->____continued;
            }

            ...where underscores are spaces, because Slashdot messes with spaces, even in <code> sections.

            • by Teckla (630646)

              And when you use tabs, it doesn't matter what tab size they assume. That is the point. Proper use of tabs means you use tabs to indent to the block level and spaces for further indentation, like so: { <-tab->a = long expression <-tab->____continued; }

              ...where underscores are spaces, because Slashdot messes with spaces, even in <code> sections.

              It does matter, because some tools that are hard coded to 8 space tabs make things hard to read, like side by side diffs.

              Also, I have used editors, like the AS/400 editor SEU, which displays a single inverse block character for tabs. It was pretty much impossible for me to maintain that code until I converted the project from tabs to spaces.

        • by swillden (191260)

          I use tabs because anyone can set the width to whatever they like (2, 4 or 8 spaces usually).

          That only works if you're also careful to use spaces for all additional indentation used to line things up -- and in many cases lining things up can significantly improve readability.

          I used tabs for base indentation (to the block depth) and spaces for extra indentation for a while, but even with good editor support I ultimately decided that it just caused me to spend too much time playing with whitespace.

          If you want your code to look good no matter what the tab width is there's only one practical way:

      • Re: (Score:2, Informative)

        by Anonymous Coward

        Tabs indent, spaces align. Your code should look equally good no matter whether tabstop is three characters or eight.

        • by Anonymous Coward

          Tabs indent, spaces align. I do this with my own code too. When I use different editors with different tab settings, I often don't even change the tab setting, my code still aligns nicely, just bigger indent. And this is from someone how loves to align things, even inserting spaces or changing variable names to get all "=" nicely linked up in variable initialisations.
          Even when I break lines (on my small netbook screen), use the appropriate number of tabs to match the indent, then align the
          rest with spaces,

      • by A Friendly Troll (1017492) on Saturday October 27, 2012 @03:13PM (#41790831)

        Out of curiosity, why do you prefer tabs? Seems like unless everyone has the same tab size set, it can make the code more difficult to read than spaces.

        For the same reason why CSS was invented to style HTML. Tabs are entirely font-agnostic and they are semantic. Spaces are not, and are directly visual.

        There are people who like two characters of indentation and there are those who like eight. Some like six! There are people who like proportional fonts for coding. There are people who like special narrow monospaced pixel fonts. Even Consolas on Windows, a very popular coding font, is narrower than the standard monospaced width, so code is less indented with Consolas than Courier.

        Tabs are also easier on the eyes if you have "show special characters" turned on in your IDE. Also, tabs are easier to work with if you ever need to run some regex on your code.

        There are no benefits whatsoever to using spaces, only downsides.

        • For the same reason why CSS was invented to style HTML. Tabs are entirely font-agnostic and they are semantic. Spaces are not, and are directly visual.

          We're talking about code here. Is anyone using anything but a monospaced font when viewing it?

          • We're talking about code here. Is anyone using anything but a monospaced font when viewing it?

            Yes, plenty of people. I was using a proportional font for a while when I had a low-res monitor and needed more stuff on the screen. I have two coworkers using proportional fonts right now.

            What is readable to one person might very well not be readable to someone else. That is why some people like their code on black backgrounds and some will get severe eye strain if they look at white-on-black for a couple of minutes.

            Nevertheless, see the post above about monospaced fonts wildly differing in character width

            • Yes, plenty of people. I was using a proportional font for a while when I had a low-res monitor and needed more stuff on the screen. I have two coworkers using proportional fonts right now.

              I havrn't seen this first-hand, so thank you for the information.

              (I'm not being snarky - and on Slashdot I do feel the need to say that!)

              • by A Friendly Troll (1017492) on Saturday October 27, 2012 @03:47PM (#41791111)

                Here's the funny thing, and I'm honestly not joking: one of these guys is using Comic Sans as his coding font, as he's dyslexic and it helps him. The other is using Tahoma, because it's very narrow.

                Visual preferences vary. That is why we are able to set our own fonts and colours in our IDEs. It is strictly a personal thing. I'm a black-on-white guy, but the Tahoma guy from above is using the old Borland nineties colour scheme, yellow-on-blue. Strangely enough, I "grew up" on those same colours, and since switching to LCD monitors, I can't stand it any longer. No idea why...

            • by AuMatar (183847)

              Some people don't even use a font- I work with a blind programmer. He uses a screen reader.

        • by coldmist (154493)

          There are no benefits whatsoever to using spaces, only downsides.

          Yes, when you have your HTML editor set to show 2 character indents for tabs, but your browser's 'view source' option shows it at as 8.

          Besides using a non-monospace font, it will always look the same no matter what editor you (or someone else) brings it up in.

          Flexibility has it's downsides, just as being too rigid has its downsides.

          It's a choice. Most people pick one and stick with it.

        • by sribe (304414)

          There are no benefits whatsoever to using spaces, only downsides.

          Until you want to evaluate some code, and paste it into some console which treats tab as auto-complete. I generally much prefer tabs, but this behavior drives me nuts, and has in some cases pushed me to spaces--and now I'm remembering how much I hated all the nonsense with spaces...

      • by Onuma (947856)
        It started when I was learning code as a teenager and just stuck. I don't code much anymore, as I'm more of a hands-on guy these days, but I suppose it's habit now.
    • Well they are clearly superior. That is the entire point of a tab. Why use the space character as a crappy replacement when you have tabs.

  • Learn one word (Score:4, Insightful)

    by roman_mir (125474) on Saturday October 27, 2012 @02:58PM (#41790679) Homepage Journal

    Learn one word: consistency.

    Be consistent from one piece of code to the next, from one project to the next. Be consistent about your design ideas, be consistent in your thinking. It's going to help you and anybody else working on the same stuff.

    Everything else is sugar.

  • I do not see any point in coding styles whatsoever. All they do is slow down coding for all but the two guys that actually like the coding style as defined; for the rest it's needless busy-work to comply.

    I agree that one persons code should look consistent; so someone should pick a style and stick with it. Also if I am making a SMALL change in someone else's code, I try to mimick the style of code around it.

    It's so easy to run a code formatter on something now that someone else can read code however they

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      Note to self, don't hire this one.

      The reason we enforce code style is the same that we enforce requirements traceability. We must have maintainable, auditable code. If we were writing throwaway scripts to delete old comments on a website, perhaps that would be okay. However, when we're writing production code that needs to work and be maintained, code style is very important. Yes, we audit code. Yes, it works. We have yet to have gotten hit with a real-world exploit, critical bug or unexpected behavior from

    • I do not see any point in coding styles whatsoever. All they do is slow down coding for all but the two guys that actually like the coding style as defined; for the rest it's needless busy-work to comply.

      It depends. Some people here seem to be defining "readability" and "documentation/comments" as coding style - and I do think readable, well-commented code is important.

      Otherwise I tend to line up with you. I will admit, though, that I've never been part of a large group jointly working on a software project. When I'm dealing with another person's code, most of the time it's something another person wrote by himself, and I'm now having to add some feature or fix some bug after the fact.

    • by Misagon (1135) on Saturday October 27, 2012 @03:29PM (#41790979)

      Coding style is not just be about making code look pretty (according to someone's personal definition of pretty). The purpose of a coding standard is to make the code more readable and thus, more understandable. Having the code look consistent helps in that regard.
      Most of the time as a programmer is not spent on producing code but on skimming through other people's code and trying to figure out how something works, or why something doesn't work. Time is money, and it is better that a code writer spends a few extra seconds on making the code more readable than a code reader spending maybe fifteen minutes on the same piece of code because he misunderstood some detail of it the first time around because it was written in a weird way.

      There are some things that are more important than whitespace and braces, that are too often overlooked. A coding style/code standard should also include conventions for code patterns, comments and how to choose reasonable variable names ... and these things can not be changed by a "pretty printer".

      • by AuMatar (183847)

        I've never seen how to choose variable names or when to comment in a coding style. Typically, people are expected to just know that. Every coding style guideline I've ever used has been nit picky bullshit about braces and spacing, enforced by that one anal retentive asshole every workplace seems to have.

      • The purpose of a coding standard is to make the code more readable and thus, more understandable.

        That is EXACTLY why you should let people code the way they like, as long as the way they code is consistent.

        Developers have a natural coding style they find more readable, letting them work on code they find more readable is beneficial in development.

        When you are done, yes you will find modules where code differs in look. But that does not really matter; generally code is understandable by those coming along l

    • Re: (Score:2, Interesting)

      by lkcl (517947)

      I do not see any point in coding styles whatsoever.

      then you have never worked on a free software collaborative project; you have never submitted patches to free software projects; you have never worked for a large software engineering firm with ISO9001 (Software TickIT) practices in place; in fact you have probably never worked with revision control tools ever in your life.

      please allow me to know exactly who you are so that i never, ever employ you or allow you to go anywhere *near* any of the free software projects i am involved in or will be involved in,

      • then you have never worked on a free software collaborative project; you have never submitted patches to free software projects; you have never worked for a large software engineering firm with ISO9001 (Software TickIT) practices in place;

        I have worked with large engineering firms; I have not have submitted small patches to OS projects long ago but as I noted, for small changes I mimic existing coding style.

        I have worked with dozens of teams ranging in size from two to thirty or so.

        in fact you have probab

  • by Anonymous Coward

    Mine is best, yours sucks to the extent that it isn't mine and most editor/IDE authors are too lazy to make mediating style a critical feature; but they seem to be slowly getting there. Now get those goddam spaces out of my indents so I don't have to get carpal tunnel, or else make me an editor smart enough to automaticly import them as tabs and export them as spaces so that we can just. stop. talking. about it.

  • There are no shortage of automated systems perfectically capable of (re)formatting code. For this reason personal choices with regards to tabstops, bracing, spacing and general layout simply does not matter.

    As far as non-decorative conventions and comments..consistency obviously generally helpful.

    I do believe there is diminishing returns on overdoing it with added danger of folks not being able to function effectivly in environments where code is produced by other groups outside your administrative control

    • by clodney (778910)

      There are no shortage of automated systems perfectically capable of (re)formatting code. For this reason personal choices with regards to tabstops, bracing, spacing and general layout simply does not matter.

      Until source control systems work on semantics and not textual diffs, it is not as simple as that. If I get your code, reformat it to my style, change 2 lines and check it back in, I have completely polluted it as far as a diff goes.

      If you want to have a rule that says all code gets run through a formatter prior to check-in, that would work, but it would mean that everyone would spend lots of time converting to and from the approved check in style.

      • by Fwipp (1473271)

        I'm not advocating this, but it's simple enough to do this with, say, automatic git hooks (pre commit, reformat the code, on checkout, format it back how you like it). No extra work on the developer's part.

        • Your assuming that reformatting the code is reversible. Semantic information can be lost in the first change that can not be recreated on commit from the source document. There would still be plenty of risk for fake difs.
      • by AuMatar (183847)

        Unless you use a version control method which can autoformat on checkin and checkout

  • Python Reference Manual: 2.1.8 Indentation [python.org]: Leading whitespace (spaces and tabs) at the beginning of a logical line is used to compute the indentation level of the line, which in turn is used to determine the grouping of statements. First, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight (this is intended to be the same rule as used by Unix). The total number of spaces preceding the first non-bla

    • by mrbester (200927)

      Which is all fine and dandy if your company primarily writes code in Python where the whitespace is a fundamental part of the language. For everybody else who has to switch between C++ / Java / C# / CSS / HTML / SQL / JavaScript / Perl / PHP etc. and doesn't use Python *at all* there are "best practices" for coding style in each, most contradicting each other.

    • by AuMatar (183847)

      And that's why I've wasted weeks of my life fixing Python bugs due to developers using different amounts of spacing. Python took the worst possible path- requiring whitespace to have meaning, but not requiring a specific type/amount of whitespace. Had they made n spaces the requirement for an indent and anything other than n an error, it would have been fine. As it is, it's completely broken and a large cause of errors on every python programmer with more than 1 dev I've ever worked on. It's to the poi

      • Well maybe that's going to be fixed. Let's see:

        >>> from __future__ import braces
        File "", line 1
        SyntaxError: not a chance
        >>>

        Nope.

        PS: That's real, try it yourself

  • This isn't the sort of thing anyone really disagrees with. It is more of a learning article, or a "I have expertise in this field and here is proof" article, than anything really worth discussing on its own merits. Even the inevitable tabs vs spaces, same line vs next line bracket discussions have little merit: In a large organization/community - its best to stick to published guidelines for a given language.
  • by gman003 (1693318) on Saturday October 27, 2012 @03:24PM (#41790931)

    I don't really care how you *format* your code. Do you put the brackets on the same line as the beginning statement? Do you put a space between the function name and parentheses? Do you double-space your code? I don't give a fuck. That's all syntax. It's easy to figure out.

    Coding style is more important to me, how the actual *code* works. Do you initialize your variables as soon as possible? Do you properly use for loops and while loops? If you use recursion, does it make sense? Do you give your variables meaningful names like $activityType, or useless ones like $_a? How do you decide when to break something out into a function?

    I work on a project with several other people. We all have our unique styles, both for format and for code. I, for instance, have been told I code with a "LISP accent", rarely storing the return values of a function in a variable, rather using the return value as an argument to another function. Another puts a blank line between nearly any two statements. Another assiduously follows some code formatting standard nobody else in the company has read.

    Although it can make it harder to work on each other's code, it has one benefit - you can easily tell who wrote the code. "Putting the braces on a new line? This must be Pete's code!" or "There's an underscore at the front of every variable name? This must be Jimmy's code!" or "There's a for loop that starts ''for (;;){''? This must be Kevin's code!".

    And if I do go in to "someone else's code" and change or fix things, I follow their style, more or less. Unless I'm completely rewriting a section, or making enough of a change that it should be considered a rewrite.

    • by AuMatar (183847)

      I like you. There are style things that are important, but it's not how the code is laid out in the editor. Concentrate on the important things, not the things everyone has to deal with.

    • As said, coding style on that level is something everyone who writes code professionally can adapt to.

      When learning at university I was very focused on writing the cleanest, best coding style possible and that kind of focus has paid off. You end up rewriting code many times but at the end you just get it, your code feels right and people tell you your code is good.

      If you haven't spent every day of writing code back in university trying to figure out how to write clean code then you're more than likely one o

    • by dfghjk (711126)

      "Although it can make it harder to work on each other's code, it has one benefit - you can easily tell who wrote the code."

      and that's SO worth the price of admission since it's so hard to achieve that otherwise.

      "And if I do go in to "someone else's code" and change or fix things, I follow their style, more or less."

      Which really helps everyone tell who wrote the code. ;)

      It's amazing how hard people are trying to justify their own prejudices here.

  • 1. Use spaces instead of tabs.
    2. Make your code readable by humans.

  • Consistency is nice, but comments are way better. I could care less if someone uses spaces or tabs between shit, as long as it has comments about what the code is doing or trying to do, I'm happy. Well, was happy, I don't really code anymore.

  • Style is Substance (Score:5, Informative)

    by afgam28 (48611) on Saturday October 27, 2012 @03:31PM (#41790995)

    The best article that I've ever read on coding style is Style is Substance [artima.com] by Ken Arnold.

    I won't repeat what he has to say here, because he explains it better than I could. But I wish that more programming languages would follow what he is advocating, because we waste way too much time arguing about braces and tabs.

  • Nice to be reminded of these ideas. While they come up most prominently in our early years as software developers, we tend after a decade or two either to take them for granted (should we be so fortunate as to work in a place where everyone writes clean code as a matter of course) or perhaps to give up on them in despair (when working in a code maintenance regime that puts a priority on generating minimal diffs where the code base is - and must perpetually remain - an ugly steaming mess.)

    The practice of
  • by Animats (122034) on Saturday October 27, 2012 @03:36PM (#41791025) Homepage

    Just use Artistic Style [sourceforge.net] for C and its derivatives C++, C#, and Java. I usually set it for "--style=ansi", but that's a project preference. External code is run through Artistic Style before use. This way, everyone knows the indentation is consistent.

    For Python, of course, there are few formatting options, so this isn't an issue. Dreamweaver will indent HTML. Javascript remains a problem.

  • Almost all the posted comments are talking about formatting (tabs vs spaces, indentation, line breaks, etc).

    While its good to be consistent with these. Style is so much more.
    Consistant naming schemes for variables/functions/classes/methods etc.
    Useful and meaningful comments.
    Handling non-expected input and states gracefully
    Catching and handling of exceptions
    meaningful feedback to the user if there is a problem.

    I would call all these

    • Max number of lines in method.
      Max number of lines in file.
      Cyclomatic complexity.
      Use of standard design patterns. (factory, singleton, adapter, and iterator)
      What subset of the languages commands are not allowed.
  • In my experience, "messy code" is a good indicator of "messy development". I strongly believe that the structure and appearance of the code is a insight into the developer's brain. And messy code: Usually means trouble ahead.

    And yes: IDEs can help with automatically formatting code: It's good since it allows developers to spot obvious mistakes, and it's bad because it allows bad developers to hide structural errors. But probably good overall.

    There's more to coding style than simply inde

  • KR (Score:5, Informative)

    by SpaghettiPattern (609814) on Saturday October 27, 2012 @04:09PM (#41791311)
    Kernighan and Ritchie stands for an exemplary coding style. It's spirit can be transferred to more modern languages. It was thought of with readability and screen economy in mind.

    My does:
    • Never omit braces for conditions and loops.
    • Spaces instead of tabs. This is a holy war which I have fought with myself. Stated with tabs but after years of persevering I realised spaces had less issues.
    • In related projects, choose one style and stick with it.
    • Let the IDE do the code formatting for you.
    • At any cost, avoid the order of members to be significant.
    • If you need fancy formatted comment then your design may need a review.
    • Design your software to be a set of modules and develop each module as pure as you can. Solving one problem well reflects in the code you produce.
    • Divide your compilation units in units containing data structure definitions and units containing processing code. That also makes your code more readable.
    • Learn from better programmers and become a better programmer every day.
    • Avoid the pitfall of cryptic programs. The more people can read you code the better it can be maintained.

    My don'ts list is getting shorter and shorter. Most programmers have reasons why they produce the code the way they do. Lack of experience should be met with understanding and appreciation for improvements.

  • When writing code everything matters.

    Forcing people to follow a style I think is counter productive. It prevents the styles from evolving. In recent years for example people have been moving towards using better naming rather than commenting.

    Strict rules prevent creativity and for that reason I disagree with the conclusions of the article to require one. Requiring anything more than just to follow a style no matter what that style may be and to try to maintain the existing code in the style that it was in i

  • Format your code so that the coders can read it.

    If your'e on your own, format how you like.

    If you're on someone else's project, format how they like.

    The compiler truly does not give a rat's behind about it, so approach it as a people issue.

    And that means being prepared to capitulate if someone else in charge wants things done their way.

  • The compiler doesn't care how you format the code.

    Your boss, however, might.

A rock store eventually closed down; they were taking too much for granite.

Working...