Are you a code neat freak?

Question

How do you handle ugly code? Are you a code neat freak?

• Do you feel that you have to clean up a file of source code before you can do anything useful?
• Do you have the urge to refactor bad structure when you see it?

I admit that I'm often tempted to clean up other people's code when I have to modify the code anyway. Bad code is a pet peeve of mine.

How about you?

EDIT: I've read the discussion about subjectivity in the comments, and that subjectivity should be avoided in SO because the goal is to have neutral questions about technicalities. I've already answered questions here about Landau-O notation, C++ declaration and definitions, network addresses and such. But I feel like I'm being forced to move everything that might be subjective off SO. I would like those who think SO must be cleansed from all subjectivity to think a bit about why a community succeeds. To my mind, it's a mixture of hard facts and softer topics. If you read the current SO topics you will find quite some subjective topics (like best books wanted etc.). People like the format for poll-like questions, too. Why not support them? Those who want a completely objective SO could get a switch that filters subjective-tagged topics out in the first place.

Answer 1

Yes, I am.

Answer 2

For formatting I am. If the code isn't indented correctly I don't feel as comfortable with it.

Answer 3

I am not. I value function over form in code.

I try to write neat code, but I don't feel compelled to alter other people's code or reprimand them for their coding styles if their code is functional and not too awful. Everyone has their own tastes, and you need to keep an open mind.

Answer 4

Yes.
#define uglyCode codeThatDoesNotTellWhatItIsDoing

Answer 5

I find that neat code takes less time to understand so for me I see it as laziness and lack of caring on the part of a programmer who does not keep his/her code clean. I do usually start cleaning up code if it is something that I have to work on.

Answer 6

Same for me. It's bad when a file contains a mix up style of several coders and I usually talk to the other developers if I think something is really bad there. I expect they handle it similar.

Answer 7

I am, and I'll rewrite other code if I know the area well enough, and I know they are wastefull. I worked with some ex-Java programmers who, in ruby would write

def foo
  if x == 1
    return true
  else
    return false
  end
end

I felt compelled to rewrite that to

def foo
  x == 1
end

But that's just me.

Answer 8

As much as I hate poorly indented code and ^Ms everywhere, I fight the urge. Reformatting code that is messy creates unusable diffs in version control, making it hard to understand what the change was. If something is so bad that I cannot deal with a reformat, I reformat it and check that in, indicating as such, and then do my work. This at least leaves a better trail of the changes.

Answer 9

Yes, I'm always tempted to make things cleaner. I try to resist the urge when I am making minor modifications. If I am doing a major modification, then I will be a little freer in my cleaning and refactoring.

I always feel free to add Javadoc (or whatever is the equivalent in your world) as long as I can understand the existing code well enough to do it accurately.

Another factor is whether you have a good test environment. Whenever someone checks in, our build server kicks off a build and around 20,000 unit tests. That gives a little comfort when refactoring.

Answer 10

If I inherited code that I will have to make some major modification I must must clean it, refactor (extract methods usually, change some variable names, ...)

I have to make some friendly surrounding before I start making modifications.

Answer 11

1. If I just wrote the code, then I clean it up before committing it.
2. If I need to modify existing code (add new functionality or fix a bug) I refactor it first so that my changes fits in nicely.
3. But I don't go looking for perfectly working and tested code just to clean it up as I have other things to do (1 and 2).

Answer 12

• Do you feel that you have to clean up a file of source code before you can do anything useful?

No, I can ignore general ugliness when modifying other peoples code but I do tidy up around the area that I'm working on. Otherwise it becomes too hard to make sure what I'm doing is right.

• Do you have the urge to refactor bad structure when you see it?

Yes, absolutely. But you can't give in to every urge, can you?

Answer 13

Yes! As our project grew in size of the development team, it became necessary to establish shared coding guidelines (with Eclipse, its easy) and require code to be formatted per the guidelines. When we hit a good breakpoint, i.e. very few major branches outstanding, we tagged the project, reformatted the whole thing, checked the new formatted code in, and tagged again.

Answer 14

Absolutely. I am constantly refactoring code as I read it, constantly renaming variables, methods, etc. to have names that accurately match their behavior. When I come across code that is too messy to deal with at the current moment, I tag it with a todo so I can come back to it later.

//todo smelly code - reason why code smells (duplicate to function blah, etc.)

Answer 15

Not as long as its readable and maintainable. I refactor when I see code that isn't both of those (and is reasonable to refactor).

Just changing the formatting or logic style is rude if isn't your code to start with. How would you feel if I went round your house and started re-arranging the furniture?

Answer 16

I sometimes judge the quality of my code just by how it looks. Without even considering what it is actually doing there is a certain "look" that I expect my code to have (lines of code per method, IF statements, comments, general complexity, etc). Almost always when it "looks wrong" there actually ends up being some design flaw.

Answer 17

Our team uses Resharper in Visual Studio, and we generally remember to run either Cleanup Code or Reformat Code when we check in. Easy, and it ensures that all the nitpicky little things like braces and spacing are all uniform.

We most definitely refactor when we hit areas of bad code. The only caveat there is you can't let yourself get sucked into it - only refactor the part you're working on and resist the urge to extend your modifications further into the system. If you're not careful you might cause your productivity to look low, even if the code is perfect down to EOF markers.

Answer 18

When someone hands me a giant blob of SQL without any line breaks, I usually have to manually reformat it to follow along and spot errors.

Telling the developer who wrote the code that I'm not as clever as them and need to break it into chunks to read it usually gets me out of any tense confrontations about changing their code.

Answer 19

It depends on which kind of ugly. I think there are two kinds of ugly. Here's some Rails code that, IMO, is not formatted well:

class User < ActiveRecord::Base
  has_many :posts
  has_many :comments
  validates_presence_of :name
  acts_as_voter
  has_one :community
  validates_presence_of :password 

  def can_has_cheeseburger?
    has_role?(:has_cheeseburger) 
  end 

  def can_vote?
    has_role(:vote)
  end
end

So, that code is a little ugly because it is sorta badly formatted, and sorta needs refactoring. I'd take a "clean as you go" approach. First, if I ever need to touch the associations section of the code, I'd end up doing this:

class User < ActiveRecord::Base
  has_many :posts, :comments, :opinions
  has_one  :community

  validates_presence_of :name
  validates_presence_of :password 

  acts_as_voter

  def can_has_cheeseburger?
    has_role?(:has_cheeseburger) 
  end 

  def can_vote?
    has_role(:vote)
  end
end

Now my code is grouped into logical sections a little more nicely, which makes it easier to find things. If I ever have to touch this class again to add another role-inspection routine, I'd see the need to refactor and either metaprogram the can_* methods, or replace them with:

class User < ActiveRecord::Base
  has_many :posts, :comments, :opinions
  has_one  :community

  validates_presence_of :name
  validates_presence_of :password 

  acts_as_voter

  def can_do?(role)
    has_role?(role) 
  end 
end

But I wouldn't rewrite the whole class once I opened it just to feel comfortable with it. That'd be a lot of energy, and I am a lazy programmer. hopefully the good kind of lazy.

Answer 20

Yes I am, but to a purpose. The act of cleaning up the formatting for instance, which I do by hand, causes me to read the code and understand the logic nesting.

Answer 21

I approach writing code in very much the same way as I approach writing in general -- Revise, Revise, Revise.

In the first pass, my goal is simply to get my ideas on paper.

In the second pass, I generally try to organize it a nice structure.

In the third pass, I try to polish it as much as I can.

Then I send it to a peer for review, who will mark it up with the red pen.

Answer 22

Yes, I am. However, the IDE's are powerful enough that they should go beyond this. Why store formatted Java in files? Compilers don't give a damn about coding style. Store unformatted Java and then apply user-defined coding styles when the file is read. Heck maybe store the Java as XML and use a used-defined XSL file to display the code.

Answer 23

I definitely do neaten code that I have to work with. If you're a fellow code neat-freak, you might want to look into the Red Gate SQL formatting tools. They have SQL Prompt and SQL Refactor. I haven't tried either one yet, but they look pretty nice.

Answer 24

There are many forms ugly, but most of the "broken window" offences tend to be purged when I find them. they really frost my lizard:

bad formatting - since we have a pretty printer with standard settings is inexcuseable. I format stuff and commit those changes to satisfy the "its hard to track the change" folks.

code that is commented out and left for dead after a commit.

hints and warnings - especially declared and never used locals. thats just lazy

Answer 25

I try to focus my refactoring efforts on code that I think I will need to change in the near future. Most projects have tons of code, but most of is static for a long time. Refactoring introduces risk, so I want to make sure that the risk is balanced by the benefit.

If I know I'm going to change a peice of code for a fix or feature, I refactor first. I try to refactor to the point where the functionality change is simple, clear, and obviously correct.

If I've just changed a peice of code for fix or feature, I've usually made it a little uglier in the process. I also am more likely to come back to this area in the future. So, I refactor again.

When my refactorings hit many lines of code, I make a point of committing the refactoring separately. I'll put "REFACTORING" at the start of the description, so when I'm reading the change history, I know which ones to skip when looking for deliberate behavior changes (or to read, if I'm looking for accidental changes!).

When a change really hits a lot of lines (e.g., reformatting), I tell my teammates first, sync up to the latest, make the change, check in quickly, and tell my teammates to pick up the change. This reduces the hassle of merging.

Answer 26

Absolutely! Keeping code clean and neatly formatted is the easiest thing you can do to improve readability. The effort required is ridiculously small considering the benefits.

Answer 27

There are different issues you need to manage - especially in a larger team

1. Merge issues caused by

(a) Different people using different editors/platforms - resulting in different whitespace standards

(b) Different people having different views on EOL vs newline curly braces (K&R style vs others)

1. You want to free people up - so have code as clean as you can - without wasting people's time. So whatever 'automated cleaning' is available - you should enforce this. In eclipse for java - this limits you to: (a) Curly brace at EOL or not (b) Tabs vs no tabs Any more than this - and you're making it hard for your team unjustifiably.

That's it. The full post on this stuff is here:

http://jumbleagilemanuals.blogspot.com/2008/03/why-your-team-needs-coding-style.html

Answer 28

I am a code neat freak, but I don't indulge myself. Every edit to working code is a potential liability. I will only clean up code if that is the task at hand. It irks me not to clean it up, but I've learned to let go.