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.
  • 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 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?
  • 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.

  • by SuperKendall (25149) on Saturday October 27, 2012 @02:59PM (#41790687)

    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 like if it's really important. But while code is underway conformance to a specific style is not helpful.

  • 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 Anonymous Coward on Saturday October 27, 2012 @03:07PM (#41790773)

    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 garbled input.

    Is writing code this way slower and more expensive? Hell yes, if you believe that SLOC is a good measure of success. However, we care about lifecycle cost, and our approach is working very well. And, it's easy to take a month of vacation when you know your code's good enough that nobody will call and ask about it.

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

    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.

  • 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.

  • 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 rgbrenner (317308) on Saturday October 27, 2012 @03:25PM (#41790947)

    a tab is a tab. It is not 8 spaces. It might be the same width as 8 spaces, but that is because your editor displays a tab as that width. Most editors allow you to change it.

    If your code style calls for tabs, do not insert 8 spaces instead of a tab. it's annoying, and you break the tab settings everyone chose for themselves.

  • 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 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 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 DrMcCoy (941651) on Saturday October 27, 2012 @04:01PM (#41791235)
    No, this just means you (and/or the people you work with) are using tabs in the wrong way.
    Tabs for indenting, spaces for alignment. Makes sense logically too, because those two functions are fundamentally different.

    I.e. it should be:

    <TAB>int_a;________//_Hello
    <TAB>int_whatever;_//_Yeah

    Where <TAB> is a tab and _ is a space.

    Works beautifully. Think, people!
  • 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.
  • by rgbrenner (317308) on Saturday October 27, 2012 @04:05PM (#41791275)

    man expand

    read it.

    And your post is exactly why people standardize on spaces. Because some people think they can insert a bunch of spaces instead of a tab, breaking everyones formatting, making diffs a huge mess and putting your whitespace changes in the commit log. Tab is not space.

    A space is ascii # 32
    A tab is ascii # 9

    stop mixing them.

  • by AuMatar (183847) on Saturday October 27, 2012 @04:19PM (#41791371)

    No, really he's not. I am quite capable of reading code with different indent styles, brace styles, etc. I do so on a regular basis, even when working with language approved styles as I regularly program in multiple languages. I have no trouble with it mixing program to program, file to file, or even function to function.
    In fact, most code bases I've worked on looked like that. And there was no noticable speedup in places that did enforce a style vs those that didn't.

    In fact, he actually tends to harm code quality. Why? Because he bogs down code reviews. Rather than looking for serious maintenance or correctness problems, we focus on his half dozen style complaints. This wastes our time and causes people to hate code reviews, or take them less seriously. The places I've worked with style guidelines all had shitty code review processes, and this was the reason.

    So no, that anal retentive asshole made everyone's job far worse. There are code style issues that matter, like naming variables well and commenting sufficiently. Formatting is not one of them, and being particularly picky about it is a BIG red flag about both a person and a company.

  • by sribe (304414) on Saturday October 27, 2012 @05:15PM (#41791781)

    Sounds like pandering to the lowest-common denominator.
    Why don't you switch to programming in VB while you're at it?

    Bullshit. If I want to search for every time that a certain condition is evaluated, I should be able to search for "if (foo.bar ==", not "if\s*\(\s*foo\.bar\s*=="

    Wait? Is that even right? Can = be used without escaping when it is outside of a capture or a positional assertion???

  • by robthebloke (1308483) on Saturday October 27, 2012 @05:15PM (#41791785)
    Why don't you try managing a large scale programming project with hundreds of developers, rather than 2 or 3? A large project has developers of all abilities, from recent grads, all the way up to seasoned pro's. In that enviornment, pandering to lowest common denominator is a good thing. For example, a coding convention that bans complicated C++ meta-template programming techniques, helps to extract the maximum from recent grads, by making sure they don't have to read 'Modern C++ Design' cover to cover 7 times before making their first commit (and that also applies to R&D folks who have PHd's in maths/physics, yet would struggle to write their own linked list template). Remove variation in programming style from the equation, and large projects suddenly start moving forward at a much faster pace. You can argue against that if you want, it just marks you out as a terrible team member, and a terribly inexperienced software developer. My 2 cents.....
  • by rgbrenner (317308) on Saturday October 27, 2012 @05:21PM (#41791827)

    Note to self; don't work for people who don't have a real account on Slashdot.

    Seriously? How is having a slashdot account a positive personality attribute? Were you too busy reading the articles to notice what gets posted here?

  • by Anonymous Coward on Saturday October 27, 2012 @05:25PM (#41791871)

    That's silly. You let the experts in your team write the "complicated C++ meta-template programming techniques" and the mediocre programmers use them. That's the point of C++-templating: Make it easy for the users of the code. It's incredible what kind of extremely convenient libraries can be written by template wizards.

    Gladly the next standard will also make it easier to write, see "static_if" proposal.

  • by robthebloke (1308483) on Saturday October 27, 2012 @05:36PM (#41791943)
    No, you're just being obtuse. If I developed with a tab spacing of 4, and I allow a maximum page width of 120 characters, what happens other people view my code with a tab spacing to 8? Chunks of code extend beyond the maximum page width, and it simply looks like an unreadable mess. Using spaces is the only way to be absolutely certain of how your code looks when viewed by other people.
  • 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 bertok (226922) on Saturday October 27, 2012 @06:16PM (#41792189)

    Seriously, what the fuck are you doing that depends on the exact way that tabs are displayed by other people!? Why would it possibly be that important? Just how fragile is your workflow that it's broken by someone else's display metrics?

    Maybe you need to take a long hard look at your toolchain, then throw it outside in a heap and set fire to it.

    I've been using whitespace-insensitive diff and merge tools since the 90s, and I reformatters since 2001 to solve even the largest formatting inconsistencies. There is never a reason for any programming task to be "broken" by the use of tabs, spaces, or any combination with any configuration. The tools to fix any conceivable problem have been around for over a decade.

    If you're finding you're writing regular expressions looking for a specific number of space-equivalents made up from tab characters, just stop. Re-think your career in programming, and considering going into the secretaries typing pool. You'd fit right in, because many of them also still haven't figured out that a tab is not the same thing as 'n spaces'.

    Next, you'll be complaining that people are putting spaces in their file names...

  • 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.

One good suit is worth a thousand resumes.

Working...