Does Coding Style Matter?

It's easy with an IDE by tirerim · 2012-10-27 06:48 · Score: 5, Insightful

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.

Re:It's easy with an IDE by Anonymous Coward · 2012-10-27 06:57 · Score: 5, Informative

... and it makes version control diffs shorter and to the point.
Re:It's easy with an IDE by sribe · 2012-10-27 07:45 · Score: 5, Insightful

... 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.
Re:It's easy with an IDE by Derekloffin · 2012-10-27 08:03 · Score: 3, Insightful

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.
Re:It's easy with an IDE by sribe · 2012-10-27 09:15 · Score: 4, Insightful

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???
Re:It's easy with an IDE by robthebloke · 2012-10-27 09:15 · Score: 4, Insightful

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.....
Re:It's easy with an IDE by Anonymous Coward · 2012-10-27 09:25 · Score: 4, Insightful

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.
Re:It's easy with an IDE by Dr_Barnowl · 2012-10-27 09:29 · Score: 4, Interesting

Having a consistent style means that you don't end up in the situation we are, where we have several patches that are probably a days work to merge with the main line, not because our patches are large, but because some bonehead decided it would be good to run an automated code reformatter on his source tree.
This not only reformatted everything to a style that no-one else on the project uses, but re-sorted all the fields and methods in the source files affected. This made everyone elses copy of the source conflict violently with essentially every change made in the reformatted files, giving everyone else the headache of re-implementing their patches.
Peoples edits continue to make the format of these files a mess because they are indented in a way that's inconsistent with the source.
Alas, we can't undo these patches because the bonehead is the lead developer. But catering to prima-donnas means more work for everyone else.
Re:It's easy with an IDE by WaywardGeek · 2012-10-27 10:03 · Score: 3, Interesting

It all comes down from the guy in charge. I've set the coding style at two of the last three companies I've worked for, and while new guys may not like it, it does promote effective teamwork. It's a lot more than just indentation. We use the same data structure styles, iterator styles, and everything from start to finish. It can be very difficult to determine who wrote any given piece of code, and a git-blame shows that it's a patchwork quilt with everyone contributing all over the place.
The guy who I will say is now the lead developer of our main software suite writes code that looks exactly like mine. We've even on occasion wrote entire functions, in the same place, which were identical down to the last character, even in the obligatory comment. No git conflict in that case. At the other company, there literally were no coding style guidelines, and the result is no one was able or willing to easily edit anyone else's code. That makes it very difficult to move people around to projects that need them most.
There are a ton of developers out there who are loners. It's a field that attracts geeks who are somewhat social-phobic. I've never seen programmers voluntarily adopt a common coding style. It's more fun to fiddle around on your own. So, instead of working together as a team to solve real problems rapidly, individual programmers go off in different directions, learning more about different ways to write code than actually writing code.

--
Celebrate failure, and then learn from it - Nolan Bushnell
Re:It's easy with an IDE by Dr_Barnowl · 2012-10-27 10:13 · Score: 3, Insightful

.. 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.
Re:It's easy with an IDE by Carewolf · 2012-10-27 10:55 · Score: 4, Funny

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.

Er by Anonymous Coward · 2012-10-27 06:50 · Score: 3, Insightful

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.

Kinda Subjective but... by Onuma · 2012-10-27 06:50 · Score: 4, Insightful

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?

--
What else can happen when an unstoppable force collides with an immovable object?

Re:Kinda Subjective but... by MrEricSir · 2012-10-27 06:59 · Score: 4, Insightful

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.

--
There's no -1 for "I don't get it."
Re:Kinda Subjective but... by Anonymous Coward · 2012-10-27 07:06 · Score: 5, Insightful

I use tabs because anyone can set the width to whatever they like (2, 4 or 8 spaces usually).
Re:Kinda Subjective but... by A+Friendly+Troll · 2012-10-27 07:13 · Score: 4, Insightful

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.
Re:Kinda Subjective but... by Teckla · 2012-10-27 07:25 · Score: 3, Informative

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.
Re:Kinda Subjective but... by rgbrenner · 2012-10-27 07:25 · Score: 5, Insightful

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.
Re:Kinda Subjective but... by Anonymous Coward · 2012-10-27 07:38 · Score: 4, Insightful

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.
Re:Kinda Subjective but... by A+Friendly+Troll · 2012-10-27 07:47 · Score: 3, Interesting

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...
Re:Kinda Subjective but... by DrMcCoy · 2012-10-27 08:01 · Score: 5, Insightful

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!
Re:Kinda Subjective but... by rgbrenner · 2012-10-27 08:05 · Score: 5, Insightful

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.
Re:Kinda Subjective but... by icebraining · 2012-10-27 08:25 · Score: 5, Informative

one of these guys is using Comic Sans as his coding font, as he's dyslexic and it helps him
Has he looked into fonts designed to help dyslexics, like Gill Dyslexic and Open-Dyslexic?

--
Dilbert RSS feed
Re:Kinda Subjective but... by rgbrenner · 2012-10-27 08:45 · Score: 3, Informative

no, it's you who broke the formatting by mixing whitespace characters.
and you don't want to type "| expand -t4", so you're going to make a mess of the commit log, make diff a mess, and force everyone else to run everything through indent.
It's sloppy and inconsistent.. and you're making it harder for everyone else on your team because of your laziness.
Re:Kinda Subjective but... by robthebloke · 2012-10-27 09:36 · Score: 3, Insightful

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.

Learn one word by roman_mir · 2012-10-27 06:58 · Score: 4, Insightful

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.

--
You can't handle the truth.

Re:Let people code how they like by Anonymous Coward · 2012-10-27 07:07 · Score: 3, Insightful

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.

Code style, not formatting style by gman003 · 2012-10-27 07:24 · Score: 4, Insightful

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.

Re:Let people code how they like by Misagon · 2012-10-27 07:29 · Score: 4, Insightful

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

--
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley

Style is Substance by afgam28 · 2012-10-27 07:31 · Score: 4, Informative

The best article that I've ever read on coding style is Style is Substance 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.

Re:Instant Code Style fix by ShanghaiBill · 2012-10-27 07:33 · Score: 4, Funny

Ctrl+K, Ctrl+F

Presto, you've got your coding style for code that you didn't write.

Doesn't work for me. Ctrl+K deletes the current line, and Ctrl+F moves the cursor forward one character. What version of emacs are you using?

Run everything through a formatter by Animats · 2012-10-27 07:36 · Score: 3, Informative

Just use Artistic Style 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.

KR by SpaghettiPattern · 2012-10-27 08:09 · Score: 4, Informative

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.

--

I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)

Re:Let people code how they like by AuMatar · 2012-10-27 08:19 · Score: 4, Insightful

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.

--
I still have more fans than freaks. WTF is wrong with you people?

Re:Let people code how they like by rgbrenner · 2012-10-27 09:21 · Score: 3, Insightful

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?

And it should never matter today! by GeekDork · 2012-10-28 00:00 · Score: 3, Insightful

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.

--

Fight hunger. Filet a politician and send him to a 3rd world country of your choice.

36 of 479 comments (clear)