Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Does Coding Style Matter?

Soulskill posted about 2 years ago | from the obfuscate-half-and-document-the-other-half dept.

Programming 479

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

cancel ×

479 comments

Sorry! There are no comments related to the filter you selected.

DD (-1)

Anonymous Coward | about 2 years ago | (#41790577)

EE

does first posting style matter? (-1)

Anonymous Coward | about 2 years ago | (#41790583)

chug my frosty piss to find out!

It's easy with an IDE (5, Insightful)

tirerim (1108567) | about 2 years ago | (#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.

Re:It's easy with an IDE (5, Informative)

Anonymous Coward | about 2 years ago | (#41790667)

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

Re:It's easy with an IDE (5, Insightful)

sribe (304414) | about 2 years ago | (#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.

Re:It's easy with an IDE (1)

Anonymous Coward | about 2 years ago | (#41790731)

Coding style is much more than code formating, e.g. naming rules, allowed language features, length limitations ...

I don't know about other industries but the automotive industry has a standardized coding style for its embedded systems called MISRA C to ensure safety, reliability and portability.

Re:It's easy with an IDE (1)

PhrostyMcByte (589271) | about 2 years ago | (#41790861)

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.

Re:It's easy with an IDE (1)

JabberWokky (19442) | about 2 years ago | (#41791023)

JetBrains IDEs allow you to do that... I can't imagine that most don't have context rules for adding blank lines.

Re:It's easy with an IDE (3, Insightful)

Derekloffin (741455) | about 2 years ago | (#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.

Re:It's easy with an IDE (0)

Anonymous Coward | about 2 years ago | (#41791003)

First post is about an IDE but doesn't mention Visual Studio. Is this a feature V.S. is missing?

Er (3, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:Er (1)

Anonymous Coward | about 2 years ago | (#41790823)

Do you really find different coding styles to be an "elaborate puzzle"? What do you do when you have to incorporate free or commercial source code into your product? Do you have to reformat it all?

Novice programmers have trouble following logic unless the code is formatted a certain way but most seasoned programmers don't care too much about that stuff. If they really do care, they run the source code through a text format utility at review time. It isn't a good idea to reformat 3rd party source code at check-in because of maintenance problems - you'll have problems applying up-stream fixes.

Re:Er (2)

Your.Master (1088569) | about 2 years ago | (#41791165)

You're stuck on the idea that coding style is just whitespace. There is not, and cannot be, a text format utility that unifies coding styles.

Moreover if you read the article, one thing a coding style could help to catch is a missed break in a switch statement. It would be wrong to automatically add a break (because it might be intended to fall through), or a fall through comment (it might be intended to break). That's a layer of defense that doesn't exist if you don't have all your code (or at least, all your new code) follow the standard of adding fall through comments, because otherwise the absence is not notable.

You don't need to reformat 3rd party source code, you just need to have a style in your code and understand the API surface of 3rd party code.

Re:Er (2)

udachny (2454394) | about 2 years ago | (#41790927)

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.

Betteridge says ... (0)

Anonymous Coward | about 2 years ago | (#41790619)

Betteridge's law of headlines says "No" ... Unfortunately, he is wrong this time! ;-P

- AC

Re:Betteridge says ... (0)

Anonymous Coward | about 2 years ago | (#41790815)

It's ok, the actual headline of the article is 'Why coding styles matter' It's just the shitty editing here that invoked Betteridge.

Kinda Subjective but... (4, Insightful)

Onuma (947856) | about 2 years ago | (#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?

Re:Kinda Subjective but... (4, Insightful)

MrEricSir (398214) | about 2 years ago | (#41790689)

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.

Re:Kinda Subjective but... (5, Insightful)

Anonymous Coward | about 2 years ago | (#41790767)

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

Re:Kinda Subjective but... (1)

slashping (2674483) | about 2 years ago | (#41790825)

Hard tabs should always be kept at 8 spaces, it's the standard, and makes all the tools work as expected without any tweaking. So, unless your code also indents by 8 positions, use spaces.

Re:Kinda Subjective but... (1)

Anonymous Coward | about 2 years ago | (#41790933)

If you like this so-called standard, set your editor's tab width to 8 spaces. Yes, that's tweaking, but unless you're using some utter crap, you only need to set it ONCE and you'll get exactly what you want. It seems much more sane that forcing your preferences on other people.

Re:Kinda Subjective but... (5, Insightful)

rgbrenner (317308) | about 2 years ago | (#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.

Re:Kinda Subjective but... (2, Informative)

slashping (2674483) | about 2 years ago | (#41791083)

Yes, most editors allow you to change, but I also use command line tools like grep, less, or diff, and they just send the tabs to the terminal which interprets them the standard way with a spacing of 8. Sure, I can set my terminal to change the tab width, but if I then grep some other sources, such as the Linux kernel tree, in the same terminal window, it gets messed up again. The solution is obvious and simple. Just leave the tab width at 8, and everything works fine, even it uses a mix of tabs and spaces for formatting.

Re:Kinda Subjective but... (5, Insightful)

rgbrenner (317308) | about 2 years ago | (#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.

Re:Kinda Subjective but... (3, Informative)

Teckla (630646) | about 2 years ago | (#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.

Re:Kinda Subjective but... (4, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:Kinda Subjective but... (1)

swillden (191260) | about 2 years ago | (#41791007)

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: Don't use tabs, use spaces only.

Re:Kinda Subjective but... (0)

Clueless Moron (548336) | about 2 years ago | (#41791091)

Tabs do not work. Don't use them. Consider this, where there's a tab before the "int" and the "//" comment using the 8-space standard and the intent is to get the comments to line up. I'm using "_" instead of spaces to get around slashdot formatting grief:

________int_a;__________//_Hello
________int_Whatever;___//_Yeah

If you set your editor, printer, viewer, whatever to use 4 space tabs it becomes this:

____int_a;______//_Hello
____int_Whatever;___//_Yeah

I for one am sick and tired of having to reverse engineer what some frustrated artistic genius decided to use for their tab offset. Set your editor to expand tabs to spaces to whatever you want and save everyone the grief of trying to figure out what you were trying to do, because I really don't give a damn if you use 2, 3, 4, 6 or 8 space indentation; I just don't want to have to guess my way to making your code line up.

Re:Kinda Subjective but... (5, Insightful)

DrMcCoy (941651) | about 2 years ago | (#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!

Re:Kinda Subjective but... (2, Informative)

Anonymous Coward | about 2 years ago | (#41790801)

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

Re:Kinda Subjective but... (2)

Anonymous Coward | about 2 years ago | (#41790923)

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, and everything behaves as it should when the tab size changes.

Following coding styles is good, especially when working on something with other people, but tabs-size should _not_ be part of the standard at all ! everyone can set the tab size to whatever they like.

Re:Kinda Subjective but... (4, Insightful)

A Friendly Troll (1017492) | about 2 years ago | (#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.

Re:Kinda Subjective but... (2)

93 Escort Wagon (326346) | about 2 years ago | (#41790891)

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?

Re:Kinda Subjective but... (2)

A Friendly Troll (1017492) | about 2 years ago | (#41790937)

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.

Re:Kinda Subjective but... (2)

93 Escort Wagon (326346) | about 2 years ago | (#41791031)

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!)

Re:Kinda Subjective but... (3, Interesting)

A Friendly Troll (1017492) | about 2 years ago | (#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...

Re:Kinda Subjective but... (1)

Giant Electronic Bra (1229876) | about 2 years ago | (#41791243)

Yeah, I remember that. Always thought it was ugly, but it seemed to be pretty readable on CGA.

Gotta agree on the whole tab thing. Logical code indents should be tabs. Thankfully I'm in charge of coding practices (and everything else) at my place, so yay we get to do it :).

Re:Kinda Subjective but... (2)

AuMatar (183847) | about 2 years ago | (#41791173)

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

Re:Kinda Subjective but... (1)

coldmist (154493) | about 2 years ago | (#41791035)

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.

Re:Kinda Subjective but... (1)

sribe (304414) | about 2 years ago | (#41791115)

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

Re:Kinda Subjective but... (1)

Onuma (947856) | about 2 years ago | (#41790989)

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.

Re:Kinda Subjective but... (1)

MangoCats (2757129) | about 2 years ago | (#41791153)

Yeah, tabs work really great in two pages of example code. Expand that out to a couple of years worth of code over thousands of pages and see how great your tabs look when opened in anything other than EXACTLY the same editor you wrote it in. If you're spending time fixing your tabs so they are portable between editors, I think your employer is not getting your brain-cycles focused on the things they care about most. Fixed space fonts, spaces not tabs (and block-column selection / copy / paste) is more productive, unless the source code is the actual product, like in a textbook. You weren't thinking about getting on my lawn, were you?

Re:Kinda Subjective but... (0)

Anonymous Coward | about 2 years ago | (#41791253)

That's why the modeline was invented. Set your parameters in the file and happy you go.

Op Op Op Op (0)

Anonymous Coward | about 2 years ago | (#41790639)

Oppan Allman Style

Bike shed effect (1)

Anonymous Coward | about 2 years ago | (#41790655)

The thing I dislike most about discussions of coding style is that since the topic of coding style has an extremely low barrier of entry, everyone has an opinion. I know bad code when I see it, I could give a fuck how many spaces are in a tab or how many characters to a line.

Learn one word (4, Insightful)

roman_mir (125474) | about 2 years ago | (#41790679)

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.

Re:Learn one word (-1, Troll)

CRCulver (715279) | about 2 years ago | (#41791139)

Learn one word: consistency.

A principle that roman_mir has put into practice through years of invariably libertard posts.

Let people code how they like (1, Insightful)

SuperKendall (25149) | about 2 years ago | (#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.

Re:Let people code how they like (3, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:Let people code how they like (1)

93 Escort Wagon (326346) | about 2 years ago | (#41790969)

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.

Re:Let people code how they like (1)

halo_2_rocks (805685) | about 2 years ago | (#41791215)

Some do, but should they really be working with you or on any kind of real project if you have to specify that they name functions and variables appropriately or that they have a design and create documentation?!? I'd rather not have to state that since it is obvious for being dismissed if you don't.

Re:Let people code how they like (4, Insightful)

Misagon (1135) | about 2 years ago | (#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".

Re:Let people code how they like (1)

AuMatar (183847) | about 2 years ago | (#41791199)

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.

Re:Let people code how they like (1, Interesting)

lkcl (517947) | about 2 years ago | (#41791159)

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, in the future.

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.

running a code formatter and then creating a patch automatically includes your modifications in amongst a bunch of whitespace modifications, by violating the golden rule of submitting single-purpose patches.

even if you were to submit a patch with a massive white-space "code formatting" modification, the existing developers would, quite rightly, tell you to fuck off. if you committed it *without* asking them then they'd be fully justified in complaining and, if you persisted, in getting you fired.

a key in the statement you wrote is "read the code". if your sole job is "reading the code", then you're not really truly involved in the development. i'm assuming that you're a useful contributor: that means you have to submit modifications. forcing *your* coding style - especially when you've clearly and up-front stated that you don't see any point in *any* coding styles - onto everyone else is bound to cause serious problems.

bottom line is: i'm not impressed. fortunately, this conversation allows everyone else to understand *why* coding styles are important.

Re:Let people code how they like (0)

Anonymous Coward | about 2 years ago | (#41791237)

That's because you have exactly zero experience of working in a team as a professional developer.

WTF per minute is the real code quality metric (1)

Anonymous Coward | about 2 years ago | (#41790693)

clearly readable code is the first step toward getting it accepted.

Valve Linux Steam Client Beta Application (-1)

Anonymous Coward | about 2 years ago | (#41790699)

"We're looking for Linux gamers to install and test our new Steam for Linux client. We are primarily interested in experienced Linux users.

In order to take the survey [valvesoftware.com] , you need to first login with your Steam account to link your response with your Steam ID."

http://securityflakes.livelyblog.com/2012/10/28/valve-linux-steam-client-beta-application-not-security-related-but-you-know-you-want-it/ [livelyblog.com]

Without Style (-1)

Anonymous Coward | about 2 years ago | (#41790713)

Your substance is questionable by anyone... At least that's been the case in the states ever since FDR left the planet in the hands of Truman, Eisenhower and McCarthy. Kennedy was assassinated. Because he had too much style. Everyone knew if he ran country, the common man would come to believe he was entitled to Style as a birthright. And look what happened, Bill Gates became the richest man in the world without so much as a hint of style.

But Steve Jobs, who cultivated style, ended up creating the largest publicly held company in the history of history, all on Style.

Gallagher was right. Us 'mericans... we may not have anything else, but we got Style!

It doesn't matter (1)

halo_2_rocks (805685) | about 2 years ago | (#41790725)

Get a program to refactor the code into whatever style you want. I'm amazed people still have make this an issue.

Re:It doesn't matter (1)

roman_mir (125474) | about 2 years ago | (#41790851)

It's not an issue of how the code looks in terms of tabs, indents, this stuff a couple of clicks away in an IDE, the issue is in consistency of naming conventions, consistency of approach to the coding decisions. Functions, methods that are easy to read are not those with best indentation, but those with clear logical path visible in them due to choices of how algorithms are split, how variables are named, whether statics and globals are used, how constants are used, what is the logic behind splitting code into sections, packages, files.

If you are consistent about those things then you really make life easier for anybody maintaining the code.

Re:It doesn't matter (1)

halo_2_rocks (805685) | about 2 years ago | (#41791229)

If that is what you mean and you have to specify that, exactly why would you hire this person in the first place and why are they programming exactly?!? I don't think you need to state obvious things to people. It makes both you and them feel stupid and it is talking down to people. It should just be assumed.

Re:It doesn't matter (1)

ShanghaiBill (739463) | about 2 years ago | (#41790913)

Get a program to refactor the code into whatever style you want.

Because when you check-in your refactored code to the {git/svn/whatever} repository it shows nearly every line as a change, and makes it difficult to see the one or two lines that actually changed. The repository quickly because bloated with meaningless changes as dueling Aspies engage in coding style wars.

Re:It doesn't matter (0)

Anonymous Coward | about 2 years ago | (#41791109)

The answer to this is that checked-in code must conform to one coding style. While everybody codes in their own style, a tool reformats the code on its way out of and into the repository. Wouldn't it be great if that worked?

Re:It doesn't matter (1)

halo_2_rocks (805685) | about 2 years ago | (#41791129)

Wow. You are a smart one. You do realize you can have a "style" that is used for check-in and one that you refactor to into when you check-out?!? But, I'm sure you never thought about it and so you make a non-issue an issue.

Re:It doesn't matter (1)

czth (454384) | about 2 years ago | (#41790941)

Sounds like a recipe for source code churn and messy revision control diffs, not to mention the difficulty of automatically reformatting any style guidelines beyond simple layout. Take the example in TFA, even - how do you "reformat" the requirement to have a throw/break/return/fall through comment at the end of every switch case? Not every coding convention can be reduced to the level of a GNU indent tool parameter.

Re:It doesn't matter (1)

halo_2_rocks (805685) | about 2 years ago | (#41791155)

Not really, as I've pointed out - if you use a refactoring program - you can have it refactor into a style for check-in and one that you use (and like) when you check-out. It isn't that hard. Most people aren't very bright when dealing with this and impose archaic rules when it isn't necessary.

Let people code how they like and (0)

Anonymous Coward | about 2 years ago | (#41790751)

Let the company use a code formatter on the final code. Or just code in assembler, only one way with it.

Re:Let people code how they like and (0)

Anonymous Coward | about 2 years ago | (#41791193)

It does matter. Here's why.

I recently took over a project from another contractor who thought that ONE line of comment per 500 lines of code was more than enough.

There was about 10k lines of code which I've had to virtually re-write to make:-
1) it maintainable
2) have some semblance of decent error handling (there was none before)
3) make it production quailty. There were so many holes in his so called production quality code, you wouldn't believe it.

He also used deeply nested if...ifthenelse rather than a case structure and obviously didn't know about functions and procedures.

Yes coding style matters. It matters a lot. If you had been coding for as long as I have (40+ years) then it is a question you don't need to even ask.

Style has always mattered (2, Insightful)

Anonymous Coward | about 2 years ago | (#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.

It depends on whatcha mean when you say style (1)

WaffleMonster (969671) | about 2 years ago | (#41790809)

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 using different conventions.

In short try to be consistent but never make a decision which presums either yourself or others have been consistent.

Re:It depends on whatcha mean when you say style (1)

clodney (778910) | about 2 years ago | (#41790889)

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.

Re:It depends on whatcha mean when you say style (1)

Fwipp (1473271) | about 2 years ago | (#41791197)

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.

Re:It depends on whatcha mean when you say style (1)

AuMatar (183847) | about 2 years ago | (#41791211)

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

Instant Code Style fix (1)

ravenknight (1844930) | about 2 years ago | (#41790817)

Ctrl+K, Ctrl+F

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

Re:Instant Code Style fix (4, Funny)

ShanghaiBill (739463) | about 2 years ago | (#41791005)

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?

Stay tuned for tomorrow's blog (0)

Anonymous Coward | about 2 years ago | (#41790829)

Does chewing food with your mouth closed matter?

Depends (1)

gnomff (2740801) | about 2 years ago | (#41790833)

It totally depends on your audience. Is this code something that must be read by one person or a hundred? If its one other person, it probably doesn't matter unless they have strong feelings. If its 100 people then you should have a standard template so people don't waste time arguing. Personally, I know that my code will be read during a code review of about 5 people. I need to make sure that all of those 5 people are comfortable reading it. For example, I happen to be working in C# and some of my co-workers hate the var type declaration, so I don't use it. Some of them have strong feelings about always using braces, so I do. At the end of the day, as long as your code is easily understandable the minutia of style guides are just to keep other people from getting their knickers in a twist. That can be far more important than whatever code you are working on.

Do not invent a coding style (1)

Anonymous Coward | about 2 years ago | (#41790837)

Dont invent your own style guide, use one from a book. Like Clean Code.
This prevents discussion and new team members might already know the rules when they join in.

What's important is consistancy (0)

Anonymous Coward | about 2 years ago | (#41790839)

Little differences -- like whether you put your bracket on a separate line from your condition, or how many blank lines you put in -- are not really important. What's the most important is that, when you modify existing code, you match the style of that code. Nothing's worse than a block of code that follows a different style than the code around it.

A consistent style can be very useful (0)

Anonymous Coward | about 2 years ago | (#41790867)

I've worked at a company that had a product that was open source (GPL & LGPL). We licensed the source code to other companies under non-GPL terms. One of the things that made our large project useful to them was the consistent coding style we used throughout. None of us loved the style, but it wasn't terrible and having 20+ developers all write the code the same way with the same conventions made it much easier for us to work together and with our OEM customers.

Exception to Betteridges? (0)

Anonymous Coward | about 2 years ago | (#41790869)

This is the first headline question I've seen that should probably be answered with yes.

Though the rest of the law applies, in that it is a completely useless question.

Next week's headline: "Do code comments matter?"

Python Indentation: Style is the language (1)

theodp (442580) | about 2 years ago | (#41790877)

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-blank character then determines the line's indentation. Indentation cannot be split over multiple physical lines using backslashes; the whitespace up to the first backslash determines the indentation.

Re:Python Indentation: Style is the language (1)

mrbester (200927) | about 2 years ago | (#41791015)

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.

Re:Python Indentation: Style is the language (0)

Anonymous Coward | about 2 years ago | (#41791047)

I hate grouping by whitespace, to easy to screw up when moving/copying code. I want parentheses or at least begin/end constructs.

Re:Python Indentation: Style is the language (1)

AuMatar (183847) | about 2 years ago | (#41791249)

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 point that when I work on python, I copy the spacing from the line above and paste it to make sure it works.

Also, the choice makes it damn near impossible to use google as a resource. You can't copy paste from the web and get it to compile without worrying about the spacing on every line. Where any other language just works, and you can make it look pretty once you've tested it.

Java rulez (0)

Anonymous Coward | about 2 years ago | (#41790899)

Yes it matters. And one should not have one coding style, but follow each language naming conventions. Java, with its firm naming conventions and no legacy issues, is the far most readable code in real life, because most of the devs are told to follow the naming conventions early on. C#, on the other hand, is made to be just as readable, but due to large number of C/C++ devs coding in it, it is usually a mess, overflowing with underscores and other convention breaking stuff useless in the object oriented world.

As always, convention over configuration. Readable code is usually a good code. Can't stress this enough.. there is nothing worse, than having a team member, coding only in "his" style.

Depends... (1)

WhackAttack (2672021) | about 2 years ago | (#41790907)

In my opinion, it depends. For a single person coding and making some program (doesn't even have to be in a company) and not planning on putting on sourceforge or something, it probably doesn't matter. In a company where code is shared and debugged between lots of people, yes it does. So all in all, formatting probably does matter in the long run.

Expertise Boosting Article (1)

ohnocitizen (1951674) | about 2 years ago | (#41790921)

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.

Code style, not formatting style (4, Insightful)

gman003 (1693318) | about 2 years ago | (#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.

Formatting is the IDE's job (1)

Call Me Black Cloud (616282) | about 2 years ago | (#41791251)

There are best practices and rules a programmer should follow and those should be set at the team level...call that "style" if you want. But formatting? Who cares? The IDE takes care of that. If the diff engine on your IDE or repository can't tell the difference between code changes and whitespace changes then something's wrong. I was on a (Java) project where half the team liked braces on a new line and half didn't. When I worked on code written by someone else, the first thing I'd do is hit alt-shift-F (Netbeans) to reformat the code. I'd do the same if I pasted some code...reformat the file to get the new code formatted the right way.

Our SVN repository wasn't glutted with meaningless diffs and I didn't face hundreds of conflicts when updating code. In this modern age (despite the lack of flying cars) it's silly to have to conform to one standard to make the software happy. Software works for us, not the other way around. I use software to format code the way I'm most comfortable with...why should everyone compromise so no one is happy? Just set up your tools properly and stop worrying about formatting.

You need rules. Does not matter what (1)

archshade (1276436) | about 2 years ago | (#41790935)

When working with code written by more than one person you need rules. It helps with code review and helps new people intergrate into the project more easily. The larger the program and the more people involved the more stringent they have to be.

Of course many of the rules can be applied by the IDE/editor or post processed this is fine as long as submitted code is up to speck. It's genrally better to do it right from the beginning though.

The precise rules themselves don't make much diffrence as long as they are sensible. Consitency is key.

My two point coding style (1)

matunos (1587263) | about 2 years ago | (#41790991)

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

Comment that code!!! (1)

Nyder (754090) | about 2 years ago | (#41790993)

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 (4, Informative)

afgam28 (48611) | about 2 years ago | (#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.

Cha-no-yu (1)

starfishsystems (834319) | about 2 years ago | (#41791011)

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 software development entails in the same undertaking aspects of style, design, engineering, and science. On that spectrum, the stylistic element can seem relatively trivial, subsumed into the others. Okay, fine. What that really means is that when we encounter stylistic failings and inconsistencies, we're bound to wonder what else is wrong with the code. Style, in other words, communicates something about care and attention in general.

As a form of communication, it's interesting to consider the Japanese tea ceremony. Few human activities are so completely formalized. Its essential form is pure simplicity, where every action in every detail of movement can be given full attention. Every tea practitioner knows this form intimately. What's interesting is that this form, while aesthetically pleasing, is seldom followed exactly. It functions sort of like a carrier wave. How a tea practitioner departs from form encodes the signal, superimposed on the carrier. In feudal days, the encoded aspect was critical. It provided a way for people to communicate on subjects that were politically dangerous.

In writing software, we're probably not concerning ourselves with political intrigue. But still, how we express an idea in code provides important information. Consistency of form is reassuring, whereas departures from form draw our attention. We're bound to ask "why did he do it this way over here but this other way over there?" In good code, the reason should be evident. We should feel a small kick of satisfaction that we're inside the mind of the programmer, that we're on the same groove.

It's the kind of code we should all aspire to write. Style is not mere decorative flourish. If it is, something is wrong, because form follows function, and this would be form without function.

RULE 1 !! NO TABS !! (0)

Anonymous Coward | about 2 years ago | (#41791021)

You stupid lazy idiot !! Yes, you !!

Run everything through a formatter (3, Informative)

Animats (122034) | about 2 years ago | (#41791025)

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.

Style != formatting (2)

redfood (471234) | about 2 years ago | (#41791041)

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 things and more "style." These are the things that make it easy to maintain code after it is written. They also help to reduce the incidence of bugs.

Oh yes: it is a good proxy measure of quality (1)

Jorgensen (313325) | about 2 years ago | (#41791059)

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 indentation: The really most important concept is clarity.

If a developer cannot explain (in one sentence) what a given function does, what a given class does or what a application does: be worried. If the developers thinks they know and still cannot explain: Be very worried.

Use a language that enforces style (0)

Anonymous Coward | about 2 years ago | (#41791265)

COBOL is a good example - it forces you to indent properly with A and B columns!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>