tags:

views:

397

answers:

20

I don't know if I'm the only person in the world which gets a bad feeling in my stomach if my code isn't "pretty". For example if I get a assignment that another person has been doing before me. I can't help it to clean the code and make it look "pretty". I don't know if it's some kind of OCD.

It's like I see the code as some kind of art that has be perfect in my own code convention to look good. I don't know if you understand what I'm trying to explain here.

But are you like me, trying always to make my code look good in a aesthetical point of view even though it won't make the code better?

+20  A: 

Yes, I care about code aesthetics.. Code that is aestheticly pleasing is easy to read and therefore easy to understand.

Michael
I only voted you up because I found the current count aesthetically displeasing. Well, that and that I agree with you.
Kendall Helmstetter Gelner
Yes, absolutely. Beautiful code is not always good, but good code is always beautiful. If it generally "looks" ugly, it is a first sign of something being wrong with it.
Pavel Minaev
+1  A: 

I too find myself in such a position. Since clean code is easy to read and maintain, I always try to clean up and style my code.

Alan Haggai Alavi
+3  A: 

If you mean identation, I think it is essential.

If you mean readable (which for me is different from aesthetically pretty), it is also essential.

If you want what's written to look like flowers and birds flying, then no. I'm not concerned. :P

Samuel Carrijo
I don't mean putting in ascii art that kind of stuff. I'm talking about just pure code which you turn into art by doing it in a certain way.
Ancide
Flowers and birds - excellent idea. Time to rewrite my code formatter.
Steve B.
+2  A: 

I'm not so much concerned with whether or not it looks nice as much as with how readable it is. It just so happens that "prettier" code is usually easier to read and maintain.

Ferruccio
+9  A: 

No, I stopped trying anymore. You can't defeat an army of code monkeys.

Only with my personal project I'm aspired to make it perfect.

User
I definately know what you are talking about here. It can drive you crazy over time.
Ancide
Crazy not, just develops an apathy.
User
One of the greatest truth of the programming world.
mkato
Here's something I've thought about: sometimes, the code itself is aesthetically pleasing; other times, its functionality is. For example, although swimming in Firefox's source code might not be comparable to swimming in a jacuzzi, Firefox is incredibly useful and could be considered "aesthetically pleasing" by that token.
Joey Adams
A: 

Yes, I am shamelessly trying to acquire StackOverflow karma with silly questions.

Andrew Johnson
Why did you even bother if that's your opinion?
Ancide
Karma's a bitch, apparently
Mike Robinson
Don't worry Ancide - he's upset that he didn't think of it first. ;)
Erik Forbes
A: 

I do that as well. I find that making the code look good makes it easier to read and understand.

Zaxis
+2  A: 

Formatting code is one way (and possibly the most bang for your buck way at that) to make your code readable. Being confronted with readable code makes stepping through your program easier (whether in a debugger or code review). The same goes for sensible variable names and thinking about variable scope.

If, however, you're spending all of your time changing some perfectly acceptable notation for fields, locals, pointers etc. into some very personal Ancide-notation, then I'd be inclined to say that isn't really necessary.

butterchicken
A: 

Yes, I like to make the code look better, because it makes easier to maintain and it looks like people are concerned on making a good system.

When the code looks ugly, you don't feel yourself motivated to keep it cool.

And I feel i'm so concerned that i think my co-workers hate me =P

mkato
A: 

I wouldn't go so far as to make things look aesthetically good purely for the aesthetic value, but I do think it's really important to write code that's readable and easily understood at a glance. Especially when writing things like XML/HTML, things like proper nesting and indentation can really make it easy to quickly get a sense of the structure and allow you to spend your time zeroing in on the areas that you care about. A short, well-organized method that's easy to read visually will save time and energy vs. something that takes ten minutes to understand.

Lyle
A: 

I make very good use of the build-in code formatter within Visual Studio. In Delphi, I even use an add-in that allows me to format my Delphi code. I also try to keep each source file below the 1000 lines of code, although I'm not worried if some files are becoming longer. I use descriptive variable names and occasionally add some additional comments when I suspect that the code (and names for fields, classes and parameters) isn't clear enough for the next one reading my code.

The result is very rewarding since I once had to maintain a piece of code that I wrote 5 years earlier. It's readability made my own pieces of code in the project still very readable. Others have been more careless, though. It gave me an easy trick to recognize my own code from the garbage that was added by some inexperienced semi-programmer/manager who was only capable of writing macro's in Word and Excel...

Workshop Alex
A: 

"Pretty" and "code aesthetics" are sort of proxy words - those terms sound trivial, but (at least to me) really mean "clearly and logically expressed ideas". Clearly and Logically expressed ideas matter.

Steve B.
+1  A: 

Tidy code is more maintainable. Your brain is able to do amazing automated pattern matching on code, so you will often find that you spot bugs and problems in code just because it is the wrong "shape". I find tidiness so important I wrote a VS addin (AtomineerUtils) for adding and formatting doc comments to minimise the work I need to go to in order to keep my code tidy.

Of course, that's no reason to reformat someone else's code - you'll only upset other programmers if you change their code to your style for aesthetic reasons, not to mention you're spending a lot of time that could be put into new code, and every line of code you change is another potential bug that needs to be re-tested. So try to stop yourself going "too far".

Jason Williams
+1  A: 

I hate that my collegues always write one letter variables, short named methods that start with underscores and generally ugly code. It seems to be the standard practice around these parts.

I always make my code look good. It's a visual representation of who I am, so I have to maintain it nice and neat, and properly indented.

Sergio Tapia
I hear you there. Working with code written by others with that kind of variable structure is just a PITA.
canadiancreed
A: 

Yeah, I have to have the code indented with spaces and tab 4 spaces wide and if it is C/C++/Java code put curly brace in its own line, Emacs macros do the rest :-)

Murali VP
A: 

Simple answer: yes.

This should be a community wiki.

GreenRails
A: 

Yes, I do. And because "you can't [indeed] fight an army of monkey" (if I may borrow this from one answer), I tend to try making this less painful and to automate what can be automated, e.g. performing cosmetic checks during the build (that will break if necessary). Another option would be to format code automatically on commit but I prefer the first one.

PS: I'm using Jalopy and Maven for this when doing Java.

Pascal Thivent
+1  A: 

I think Robert Martin described it best in his Book Clean Code:A Handbook of Agile Software Craftsmanship

It’s not enough to write the code well. The code has to be kept clean over time. We’ve all seen code rot and degrade as time passes. So we must take an active role in preventing this degradation.

The Boy Scouts of America have a simple rule that we can apply to our profession.

Leave the campground cleaner than you found it.

If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn’t have to be something big. Change one variable name for the better, break up one function that’s a little too large, eliminate one small bit of duplication, clean up one composite if statement.

Can you imagine working on a project where the code simply got better as time passed? Do you believe that any other option is professional? Indeed, isn’t continuous improvement an intrinsic part of professionalism?

codeelegance
+1  A: 

Define "aesthetics." I think it means different things to different people.

The absolute most important thing to me about any code that I write (despite hasty code samples posted here) is that it works as intended. Once it works as intended, then, and only then, do I worry about the aesthetics.

Aesthetics are subjective. I may spend labor to make my code a work of art in my eyes, and someone else may come behind me and labor to change it to conform to their sense of what constitutes "beautiful code." After all, do you include design patterns, coding standards, naming conventions, and who-knows-what-else in that? Or is it a simple matter of indentation, curly brace alignment, type-alignment in variable declaration, and so forth?

No two developers will completely agree on what constitutes aesthetically pleasing code. That's not to say that you shouldn't strive to create it; but it should not be your number one priority. Writing working, maintainable code should be your number one priority. If it happens to be aesthetically pleasing as a result of that, so be it.

Mike Hofer
A: 

So your the guy making merging a complete nightmare? Undoing all the formatting that is aesthetically pleasing to me, the writer and primary maintainer of that code you just checked in?

jfar