Ask YC: What Does "Taste and Style in Programming" Mean to You?
I like to look at code and be able to say that it has been written with 'taste and style'. Taste and style means different things to different people.
What does it mean to you? What do you like to see in code or design?
28 comments
[ 2.5 ms ] story [ 80.2 ms ] threadOther than that, it's sometimes hard to describe. But it is very easy to tell if you're looking at code from someone who loves to code versus code written by someone who just does it for a paycheck.
That said, with code, I think there are a few properties which are considered 'beautiful' or 'tasteful', not in and of themselves, but combined with that impalpable aesthetic we call 'beauty'.
Of all of these, I think the only one most programmers would agree on is that truly incredible code is nominally quite brief.
That's probably true. But that makes me wonder...
People have a hard time appreciating poetry in their second or third language, because you need to have such vast knowledge to get the subtleties of the poet's intentions.
I suspect the same holds for code. The more skilled and more experienced the programmer, the more complexity he can handle. And he'll find beauty where mortals like us are simply confused.
I can't appreciate Shakespeare, but I suspect it is as great as many claim it is. I would probably dismiss Shakespeare as unnecessarily complex and verbose if I didn't know better.
Worth thinking about the next time you're annoyed at a piece of complex code, and really want to refactor it so everybody can read it. You may be destroying something beautiful.
For me, it's always a matter of simplicity. When a problem is hard to describe in English, you naturally assume the code will be a bit complex as well. And yet, sometimes, the problem can be decomposed so neatly that the parts are trivial and fit together effortlessly. For me a requirement is that after carefully reading the code you are absolutely certain there is no room left for bugs. You almost know for certain that the code didn't have any bugs when it was written down for the first time, because it captures intent so well. If you need to refactor it's probably too late already.
So I think books like "Beautiful code" got it entirely wrong. I especially don't agree with icey's opinion that refactoring can make code tasteful or that linebreaks can make or break greatness. It's about bringing human thoughts to computer code. And when that mapping is perfect, the code is great.
The open source community is a good place to start looking if you don't have someone you respect in your own community.
Excluding perhaps parts of the network stack - it's a clever and very compact code, but rather hard to follow for uninitiated.
E.g. boot.c
https://gforge.cs.vu.nl/plugins/scmsvn/viewcvs.php/trunk/src...
Maybe I'm not the best at reading badly commented C code, but Ruby and MzScheme were not nearly as pleasant.
See also: http://c2.com/cgi/wiki?GreatProgramsToRead and the linked pages, which discuss your question further.
I also like Scheme48.
http://www-cs-faculty.stanford.edu/~knuth/lp.html
"Did you hear about the rose that grew
from a crack in the concrete?
Proving nature's law is wrong
it learned to walk with out having feet.
Funny it seems, but by keeping it's dreams,
it learned to breathe fresh air.
Long live the rose that grew from concrete
when no one else ever cared."
and
"I see no changes all I see is racist faces
misplaced hate makes disgrace to races
We under I wonder what it takes to make this
one better place, let's erase the wasted
Take the evil out the people they'll be acting right
'cause both black and white is smokin' crack tonight
and only time we chill is when we kill each other
it takes skill to be real, time to heal each other"
there both from Tupac Shakur, but the first one is from the poem " the rose that grew from concrete" and the second one is from the song "Changes" The difference is that in the first one its just words put together with a meaning, they say something. But the second one i like more, because of the rime and the rhythm. The first one is written on paper and published to be read, but the second one is from a song, it has to conform to the rhythm of the song, the words are structured to fit with the music and the flow, the second one has structure and architecture and it has to be simple enough to fit with the music and the beat. Making the second one is harder and its more beautiful. When i see good code, for me that means that it follows the flow of the readers mind, the code just fits and does its job, no fancy magic stuff, just simplicity and beauty. It has to be easy to understand too.
You may have unintentionally supported the null hypothesis, that there's just no accounting for taste.
The software has to have a strong opinion about what it's doing. It's modelled the problem in a way which leads to a straightforward solution, using a minimum number of concepts.
According to the conventions of the language in which it was written, the visible structure must reveal the underlying concepts. To a reasonably experienced practitioner, the code documents itself and comments are infrequent.
You can always visit thedailywtf.com if you're lucky enough not to be exposed to bad code on a daily basis. My personal pet hates are copy-and-paste code, inconsistent formatting, excessively long lines, bad or non-existent naming conventions, Hungarian notation, and spelling mistakes - pretty basic stuff.