I understand that everyone has their own style of programming and that you should be able to read other people's styles and accept it for what it is. However, would one be considered a sloppy programmer if one's style of coding was inconsistent across whatever standard they were working against?

Some example of inconsistencies might be:

Sometimes naming private variables with _ and sometimes not

Sometimes having varying indentations within code blocks

Not aligning braces up i.e. same column if using start using new line style

Is this even something that as a programmer I should be concerned with addressing? Or is it such a minor nit picking thing that at the end of the day I should just not worry about it and worry about what the end user sees and whether the code works rather than how it looks while working?

Is it sloppy programming or just over obsessive nit picking?

EDIT: After some excellent comments I realized I may have left out some information in my question. This question came about after reviewing another colleagues code check-in and noticing some of these things and then realizing that I've seen these kind of in-consistencies in previous check-ins. It then got me thinking about my code and whether I do the same things and noticed that I typically don't etc I'm not suggesting his technique is either bad or good in this question or whether his way of doing things is right or wrong.

EDIT: To answer some queries to some more good feed back. The specific instance this review occurred in was using Visual Studio 2010 and programming in c# so I don't think the editor would cause any issues. In fact it should only help I would hope. Sorry if I left that piece of info out and it effects any current answers. I was trying to be a bit more generic in understanding if this would be considered sloppy etc. And to add an even more specific example of a code piece I saw during reading of the check-in:

Such a minor thing I know, but many small things add up(???), and I did have to double glance at the code at the time to see where everything lined up I guess. Please note this code was formatted appropriately before this check-in.

EDIT: After reading some great answers and varying thoughts, the summary I've taken from this was.

It's not necessarily a sign of a sloppy programmer however as programmers we have a duty (to ourselves and other programmers) to make the code as readable as possible to assist in further ongoing development. However it can hint at inadequacies which is something that is only possible to review on a case by case (person by person) basis.

There are many reasons why this might occur. They should be taken in context and worked through with the person/people involved if reasonable. We have a duty to try and help all programmers become better programmers!

In the good old days when development was done using good old notepad (or other simple text editing tool) this occurred much more frequently. However we have the assistance of modern IDE's now so although we shouldn't necessarily become OTT about this, it should still probably be addressed to some degree.

We as programmers vary in our standards, styles and approaches to solutions. However it seems that in general we all take PRIDE in our work and as a trait it is something that can stand programmers apart. Making something to the best of our abilities both internal (code) and external (end user result) goes along way to giving us that big fat pat on the back that we may not go looking for but swells our heart with pride.

And finally to quote CrazyEddie from his post below. Don't sweat the small stuff

16 Answers
16

You are right to point out that the users are the most important thing, in the end. But here's the point I think you've missed: Other developers are users of your code. It's as important what they see as what your application users see.

Now if it was a tradeoff -- if improving your code made the user experience worse -- then I'd have to say pay attention to the larger group (hopefully your users).

But it's not a tradeoff. You can reach both goals simultaneously. So do so.

As a side-note, if you are the only developer who will ever work on this project (disposable applications) then you don't have an immediate problem. But wouldn't it be better to get into the habit of being consistent now rather than when you're in a job with a team?

There are times when a team might make the decision to allow code to be written 2 (or even more) different ways, but that's usually on a basis of "we're going to change our approach for all new code, change code when we're in that area, but not change code that never gets touched until there's so little left that it's worth making a project of it." Those cases have to be very carefully managed.

EDIT: To answer your edits: that just makes it worse, in my mind. It's not a case of clumsy writing because the IDE would have corrected it. It looks like there was another block of code inside the inner-if, which was deleted along with the outer-brace. This is so easy to fix that there is no excuse for failing to doing so.

Once indenting gets out of control, code becomes very hard to read and even harder to debug. I don't think you're nit-picking at all.

I would also add that even if you are a single developer, if you have any intentions of ever coming back to your code - it would be in your best interest to adhere to coding standards and consistent formatting.
–
Eran GalperinMay 21 '12 at 7:04

If there's some consistency, I try to overlook it and move on. There's no need to be a perfectionist. But if the developer who wrote the code was careless, then he or she may not understand that other developers will need to read their code, and if the developer doesn't understand the concepts of readability, then this tells me something about this developer that speaks volumes:

This person does not know how to read code themselves!

In many of our careers, we don't necessarily write code from scratch. Instead of repetition, we reuse blocks of code or consume API's written by other developers, and these form the building blocks of our applications. Oftentimes, learning to use these tools involves reading API documentation and reading code examples. Furthermore, understanding modules in an internally developed project, where there might not be nice API's or code examples, involves the ability to painstakingly read and understand unfamiliar blocks of legacy code, most of which probably contains formatting and style issues itself.

When witnessing a new developer writing his own JSON serializer and asking him why he's not using Jackson or GSON, he says "It throws errors and it doesn't work. It makes no sense!"

Why was he doing this?

How a developer writes his or her code tells us a lot about his or her abilities. Considering that in most fields, a newly minted professional learns from working alongside other more experienced professionals, seeing sloppy code would indicate to me that the person who wrote it hasn't had the opportunity to learn from others, principally because he or she hasn't tried.

When mentoring new developers, we work on these points. The developer writing his own Jackson replacement gained a newfound respect for code readability when we walked through a few nicely written examples of this in action.

Once a developer experiences this first-hand, and understands that the job entails not just writing code but also reading it, their approach shifts.

Finally, if the developers you're working with aren't new and are in fact so called senior engineers, then you may want to consider finding work elsewhere. These engineers don't respect you, your time, or the organization they work for, and they don't care if you or anyone else has to clean up their mess. Badly formatted code, and I don't mean just a few missing underscores, is a sign of a pathology in the organization. It either says they're inexperienced, or they simply don't care.

Taking a sample set of 50+ developers I have worked with, I have yet to come across a developer who is consistently sloppy in their formatting yet has outstanding output in terms of code correctness, and meets all functional requirements and non-functional requirements consistently and effectively.

Sloppy formatting is a sign of a lack of attention to detail. That consistent lack of detail, in all cases in my personal experience, has invariably translated into the same lack of detail in code correctness as well.

In other words, I have never come across a great developer (high correctness and maintainability) who is consistently sloppy in formatting.

Based on this experience I use consistent, systemic and repetitive formatting sloppiness as a negative indicator of developer calibre.

I think that in a way you are partly asking yourself the wrong question. Is the code readable? Can you understand what it is supposed to be doing at a glance?

Code formatting is something that allows people who are unfamiliar with your code to feel comfortable. In some ways this is a good thing, that you might look at someone else's code and have it feel similar... comfortable. Some languages (Python for instance) require a certain degree of formatting to even work correctly. In other ways, code formatting is a distraction where the language itself isn't truly dependent on it. Do you really care if your methods are properly camel-cased, or if your private variables start with an underscore, or even if your public and private methods are in some sort of specific order?

This brings me back to the issue of readability. Your task is to encode requirements, and to communicate what you have done to the next developer who will modify the code after you. Keeping code looking neat, with nice camel-casing and consistent naming can help with this to a certain degree, but I'd argue that the attention is in the detail of what you do in the code itself. Keeping your methods short, naming all of your code elements descriptively, and removing duplication can make a greater difference than whether you are worrying about whether or not to put the curly bracket on the next line, or whether you have indented consistently. These formatting issues become more important when the code is long and difficult for the reader to parse quickly.

My point is that your code is probably already in trouble if you're at the stage of worrying how carefully formatted it is. With that said, if the formatting bothers you, it costs you very little to tidy things up as you go, provided it is within the scope of the work you are supposed to be doing at the time.

So is all of this nit picking or a sign of a sloppy coder? That largely depends on your point of view. Personally I don't think so. It could perhaps be seen as a sign of laziness or poor attention to detail, but if the code works and it's passes all of it's testing, then you might ask yourself how "sloppy" the coding really is. On the other hand, if someone else finds it difficult to read your code, then this could be a sign that your code may be difficult to maintain, and that in itself would be a cause for some concern.

If you are working within a team, or if you are likely to leave your code to be maintained by someone else, then I think it is better to keep your code neat and tidy, readable, and easy to understand. Formatting rules and style may need to be discussed as a group and some guidelines set, or encoded in a code checking tool (like StyleCop for C# for example). If it's your own personal project and will never be looked after by others then the point is debatable, although I'd argue that it's better to practice good clean coding techniques as a habit rather than something you do occasionally.

I can't help thinking that coding is all about details. Every detail of our code is important - for correctness, for readability, for extensibility, for maintainability.

While the examples given are not disastrous in themselves, to me they speak of a lack of attention to detail that I would consider to be worrying - particularly in a tool like Visual Studio which offers so much help - I use Ctrl+K, Ctrl+D almost as habitually as Ctrl+S

I work with a coder who is similarly sloppy (and also blatantly ignores our coding standards with things like no white space between methods and lowercase private method names) and over time we've come to realise that we have to keep a very close eye on his work as this sloppiness extends to his design and testing, and we've had to spend considerable effort "tidying up" behind him.

I would think that it is a sign that the developer was not using the tools available to them. If you're using a tool such as IntelliJ Idea for Java, or any of the other fully featured IDE around at the moment they make it so easy to write neat code that it's just as easy, or easier, to do it.

The problem with being lax in your formatting is as was commented on, on the original post other people reading your code are likely to be sceptical of the quality of the rest of the code. More importantly it makes the code more difficult to maintain once it becomes legacy code.

If I was doing a code review, I would be able to live with the inconsistent spacing between operators, but would most likely fail the review because of the inconsistent indenting and variable naming. Especially when one keyboard short cut will format it for your if you're using an IDE. I think when working as part of a team It's important that everyone uses the same tools and conventions to avoid mental mapping as much as possible.

I suggest as a test try putting some of that code up as part of a question on Stack Overflow or as a Review on the Code Review Beta and see what other comments you get.

Indentation inconsistencies can be the result of using differing tools/platforms. Are you indenting with spaces or tabs. How many spaces? Where are the tab stops.

In the early 90's people used tabs to replace 8 spaces and indented either 2 or 4 spaces. (Actually, I preferred 3). So some teams agreed to use only tabs and then set their tab stops wherever they liked. Of course, this later caused problems as other tools automatically replaced tabs with spaces or vice versa. Now pretty much everyone uses spaces so that at least everyone always sees the same thing.

If you want to get rigid about formatting, you can use Checkstyle to enforce whatever rules you want.

Personally, I'm consistent about some things in Java, like package names are all lower case, class names start with upper case (and nothing else does), and other common Java style practices. On the other hand, I'm not that consistent about whether or not I use braces in an if statement when I don't have to. I generally put space around arithmetic operators, but I won't in some instances, particularly if it is the difference between making the line too long or not.

The differences I see:

Do the inconsistencies make the code harder to read.

Do the inconsistencies make it harder to remember or understand the important points.

Does the construct lead to more easily overlooked errors.

Being consistent about capitalization makes it very easy to tell at a glance the difference between a class name and a variable. Being inconsistent breaks that for no good reason, and so is very bad.

Being inconsistent about spacing around arithmetic operators is probably not a problem.

Not using braces with an if statement can be dangerous as if you add a second statement to the then clause without also adding braces then the second statement may look like it is part of the then clause but actually isn't. Me not using braces may, in fact, be considered sloppy. I don't have a defense other than it saves a line, making the code more compact, which is weak, especially since I always put else on a new line rather than putting it on the same line as the closing brace of the "then" clause.

Programmers range in their styles. Some of the most ingenious and creative programmers use a strict rigidity of style as a way of freeing up mental resources. (I once beat a grandmaster at chess in a 60 person exhibition by getting him to resign by simply orienting my knights so they were facing him. He wanted to see them in profile.) Others, like me, feel that rigidity at any level inhibits creativity and chafe and rules that are not demonstrably important.

As is so often the case, it is usually best to find some sort of happy medium.

My sense is that most people are fairly consistent in their use of white space, underscores, etc. for the same reason that they spell words correctly, use punctuation consistently, wear a seatbelt, brush their teeth always starting on the same side, and so on. When you do a thing regularly, you get used to doing it a certain way and you do it without giving it a lot of thought.

At this moment, without looking at code I've written recently, I can't tell you whether I usually write foo = bar; or foo=bar;, but I'm pretty sure that I write it the same way every time. (In fact, I can tell you now that I do the former: typing the first example went quickly, but I had to think to avoid typing spaces around the = in the second example.)

If I saw someone writing code that was very inconsistent in the way it was formatted, I wouldn't necessarily assume that they were sloppy so much as one of the following:

they were inexperienced and hadn't yet developed an automatic style;

they hadn't written much code recently

they were having trouble with some other aspect of the code leading to many trial-and-error edits

the code in question was written a while ago and had been edited by several people over its lifetime

It's not clear from your question whether you're talking about your own code or someone else's. If it's your own and you're concerned about how it reflects on you, then it's something to work on in the coming weeks. Spend a little time figuring out how you want your code to look (in keeping with company coding standards), and then pay extra attention as you write code in the coming weeks. If you're really complaining about one of your coworkers, then it's probably best to not let it bother you and let your manager address it if it's a problem for the team. If you're friendly with the person in question you might gently suggest using a tool for formatting code. Many IDE's provide formatting help, and there are plenty of pretty printers and code formatters (e.g. Uncrustify) that can help.

To me, properly formatted code is very important. It allows me to quickly see structure in a program, find possible faults, whatever. When there's code that's just a screenful of text with very little spacing, it's much harder to read than when it's divided into logical blocks and some spaces between the operators etc.

Underscores in private variables are somewhat important: it's good to have a way to quickly identify a global variable, so when searching for a problem, you instantly know it probably isn't contained to that particular method.

As others have said, if a developer isn't worried about how readable his code is, there's a problem. He'll probably have to read it himself later on, and there's a good chance he won't remember what that piece of code does by heart. Perhaps he hasn't worked on a big project yet, where this is a bigger problem than in small projects.

I remember people in programming classes asking me for help, and from time to time I'd have to tell them to format their code before I could even begin to look at what's wrong. It's incredible to see how many people think indentation and correct variable naming is unimportant.

I don't think consistency is really the issue: its whether or not the code as read by another programmer accurately conveys the code's function. That depends on context.

The idea that matching braces should line up, or that the name of a variable should be indicative of its purpose are pretty universal. So someone who types braces that don't line up or who gives variables names which are contrary to their purpose is conveying false information. That is bad: even though the code may work, it might as well be the result of balanced mistakes. It is fragile and unstable.

On the other hand, how variables are capitalized and what that means is far more varied. It depends on the conventions of the language, the platform, the development environment, and most of all upon the conventions of the programming team. If there are no consistent conventions, if nothing has been written down to say "this is how it should be done", then there's no reason to expect consistent code. In other words, if a particular stylistic practice has no meaning in a given context, then inconsistency has no meaning either.

Of the original four examples, I would say that variations in 1, 2, and 4 are only meaningful if the those elements have been given well established meanings in the first place. Only #3 has a fairly universal meaning and even then I would only be critical if the alignment was far enough off to be truly misleading.

It might be argued that a good programmer should have a self-consistent style even in the absence of a style being imposed from the outside, but I think that is a false assumption. A good programmer should be able to adapt to the rules they are given, and those rules will change as they move from project to project. So if there is inconsistency in the absence of rules, it is the absence of rules not the inconsistency which is responsible for any readability problems.

I'm late to the question, but it deserves this: Computer code is the expression of the developer's intent. If the developer is not expressing or cannot express his intent to both the compiler and to the next human to maintain his code, then he is not doing his job.

If the code 'sloppyness' makes the developer's intent less clear or even gives the impression of different intent, then it is a problem. In some cases it will be a problem for the compiler, in other cases it will be a problem for the maintainer. But it is still a problem, as we don't need the maintainer 'fixing' the intent and then introducing bugs because the 'fix' was wrong.

Imagine a carpenter building a great wood piece, leaving all the tools spread all over the workbench, in a messy way, while building this great wood piece of art. Now imagine the carpenter gets sick and another carpenter comes by to finish the wood piece. When he sees all the mess around him, he loses time and patience to organize everything around him so that he can start finishing the piece the way he best knows. In the end, the wood piece is great, beautiful, shiny, and the customer buys it.

Now switch the carpenter by a software developer.

I believe the important lesson here is the client satisfaction with the software product, but also as important, is how the developers work together and use correctly the available tools they have and to be organized so that everyone can work fast and productive with each others work.

I think every developer should be perfectionist, love what s/he is doing so that s/he can have fun solving the customers' problems and leave a clean workbench (proper indentation, correct use of variables names, excellent documentation, etc.) for others to use and improve on hers/his work.

I guess it is up to the standards of the organization. If you don't have some formatting guidelines, I'd try to get it on the agenda if I were you.
Once a standard has been agreed to, you can use the formatting function of your preferred editor to make sure everyone uses the same standard. (he can even use what he likes before sending it upstream if he applies the formatting tool before sending the code to your source control server)

Concerning your worries about his standards if his code is not properly formatted: I think that it might be an indicator on how much attention he pays to details. If you think this is the case, it might be something to discuss, but this can also be caught in code reviews and the he can get meaningful feedback he can learn from. fussing about code style only is like putting form over function to me. If he writes sloppy code it will likely also show up in his quality metrics, so code style alone isn't really worth fussing about, there are tools for that.

A programmer friend of mine has dyslexia. He has no difficulty with logical thinking, or with writing code that’s functional, elegant, well-tested—everything you could reasonably expect of a decent developer. But he can hardly write to save his life, and he simply does not notice inconsistencies in spelling and formatting as much as other people, because his mind is better at paying attention to other kinds of detail.

That’s the far end of the spectrum, but you must understand that while developers must be detail-oriented, not every developer is detail-oriented in the same way, especially when it comes to aspects of the code that do not affect its actual workings.

Bottom line: if you want standard code, run autoformat and move on to more important things.