[AdamSpeight2008]

Are the Aesthetics of your Code important?
Ie. Is the way it looks as important as it's function?

Discuss.

This post has been edited by AdamSpeight2008: 04 May 2011 - 08:05 PM

[DaneAU]

If it looks like crap, when it comes time to updating it you really hate doing it. If it looks organised and well presented it makes sitting down and understanding it a whole lot easier.

[MATTtheSEAHAWK]

Definitely. I love re-writing messy code into clean code. And half of the time it works better. I was just posting this on my twitter when I saw the d.i.c. tweet. @opencoding

[macosxnerd101]

DaneAU, on 04 May 2011 - 10:59 PM, said:

If it looks like crap, when it comes time to updating it you really hate doing it. If it looks organised and well presented it makes sitting down and understanding it a whole lot easier.

This. If I can't read it, I can't debug it. So many people grossly underestimate the value of clean and organized code. It makes debugging, mainting, and optimizing the program so much easier. Just algorithmically, one can pick up on inefficiencies, potential problems, logic flaws, etc., with properly formatted code.

[codeprada]

Most definitely....it should be even more important to anyone that intends to post here for help.

[Curtis Rutland]

Interesting question. I'd say it depends, even though that's not how I voted.

I'd never sacrifice function for form, from the perspective of code. To me, that's the epitome of shallowness. I might sacrifice efficiency for readability. For example, sometimes LINQ queries may not be as efficient as manually creating the loops themselves, but it's easier to code, and debug, if you understand it and accept it. Or, for instance, I won't use bytes or shorts instead of ints even though the numbers I'm using will fit. This can lead to a lot of relatively pointless casting of literals and such, which dirty up and confuse the code, even though it'd be more memory efficient.

It is important that my code is elegant. Usually, elegant code has a nice form as well as function. I try to find a balance between not using unnecessary lines to do what I can in one statement, but not creating massive, monolithic and ugly one-line statements.

I guess the best way to put it is, I'm proud of my code when it's beautiful, but I'd never let that bar me from actually completing a task.

[scalt]

Functional == Beautiful. Code does not exist solely to produce the required output at a given point in time - regardless of how small the job is. The required outputs may change, they may grow, there may be certain circumstances when the output produced does not meet requirements. At this point the code that was once functional but not beautiful becomes code that is now neither functional nor beautiful, but the code that was both functional and beautiful evolves into code that is yet more functional and beautiful.

Basically you could view beauty and functionality as inputs into the AND gate of code natural selection. If you have both then your code will hopefully survive and spread its genes/code around to other projects. No-one wants the genes/code of some disgusting abomination of hideousness uglying up their little baby/project.

That's my 2c

This post has been edited by scalt: 04 May 2011 - 09:27 PM

[Martyn.Rae]

scalt, on 05 May 2011 - 05:25 AM, said:

Basically you could view beauty and functionality as inputs into the AND gate of code natural selection. If you have both then your code will hopefully survive and spread its genes/code around to other projects. No-one wants the genes/code of some disgusting abomination of hideousness uglying up their little baby/project.

Hmmm, I reckon we simply annihilate all developers who write sloppy code ... that would solve the problem. Then only the beautiful and functional code would exist!

This is the reason why I love assembly so much. So long as you keep your instructions and operands in the same columns, beauty is maintained. None of this "Where does the open brace go?" and "Do I leave space between all source tokens?". You maintain focus on what matters in assembly, not the aesthetics of the "beauty of code".

[Creecher]

I don't really care about how it looks until I can get a working version of whatever I'm making, then I go and make it look good.

Functionality > Looks imo

[baavgai]

I think it quite depends on what you consider aesthetics. This being highly subjective.

Messy code gives bugs more purchase, as they can hide in the unkempt corners.

In broader sense, most modern languages have chosen aesthetics. The whole Object Oriented thing is really just a way to control mess.

If the legibility of code didn't matter, we could all just write chaotic C with gotos and globals and call it a day. It works. It's the fastest code you can produce in most cases. But, well, legibility is often questionable.

[hookiethe1]

I wouldn't say quite as important as function, but still pretty important. On top of readability, which has already been pretty clearly emphasized, I'm sure many of us work in situations where code is often put up for peer review. In that case you want to look competent and professional, and presentable code can make all the difference.

[diego_pmc]

Imo, in this regard, reading code is pretty much like reading actual text. Even if the code/text is well written, if it looks bad you're not going to be very eager about actually going through it. If it looks good, you're more inclined to read it.

The way I judge is by asking other people to look at my function and seeing their expressions. Based on that and also on how much they spend trying to understand it I decide if I should improve it or not.

Edit: I should add: When I ask people to try and understand my code I try to ask those with less experience than me. If they can go through it, it's good. If someone more experienced says they understand it you can't really deduce too much from that.

This post has been edited by diego_pmc: 05 May 2011 - 04:18 AM

[Sergio Tapia]

It's very important to me. I have a lot of projects and I have to switch back and forth from them. I don't have the luxury to just work on a single thing.

Having clean code, well thought-out variable and method names, and a good document flow is PARAMOUNT for me to easily switch mindsets.

If I take more than a minute getting my bearings, it's time for some refactoring. Luckily after coding with this mindset for more than a year I notice that I have to do it less and less, I just put more time up front thinking about things before I do them.

Then there's Resharper which helps me refactor greatly. So for example, if I don't know if a certain approach will work, I just use 'x' as the main variable to save typing time. Then I refactor it to a much better variable name.

Resharper is a really great tool for me.

[Dormilich]

NeverPool, on 05 May 2011 - 10:54 AM, said:

I don't really care about how it looks until I can get a working version of whatever I'm making, then I go and make it look good.

too much work. I find it less cumbersome and much faster to make the code readable when writing it (besides the better editability).

[RetardedGenius]

I think that it's important from the perspective of readability, e.g. using: well-named identifiers, indentation and a consistent-formatting style.

I also think it's a good idea to use imperative verbs when naming void functions and nouns, or verbs, for value returning functions.

Oh and documenting code is a must, even if you're the only person that's ever going to see it!