Other Software > Developer's Corner
Beautiful Code: In your opinion, what makes code Beautiful?
Ehtyar:
To me, beautiful code is more about formatting than length/brevity. Improperly indented code is awful. Code with the {{}{}{}}{{}{}}{} syndrome is disgusting (ala tcl). Though I must admit, code like Perl, where you can do the most outrageous ridiculous things on one line is truly fascinating and beautiful to me.
Ehtyar.
phitsc:
Concerning complicated code: we have a guideline that says if one thinks he needs to explain in a code comment what a certain piece of code is doing, he should consider rewriting the respective code to make it more self explanatory. For example, often refactoring a piece of code into its own function and giving that function a suitable name makes a comment obsolete. Obviously, this way functions make a one-liner out of a 20-line piece of code, i.e. it's useful to make a function even if that function is called only once.
While I think/agree that it is usually preferrable to write something 'simpler' (which often results in more lines of code) contrary to more clever (which often results in complicated one line statements) I tend to start making 'exceptions' to that rule myself. The questions that come up are: should one use 'advanced' language features of a programming language? Which features are considered to be advanced: the complicated ones?, or the seldom used ones?, or the new ones?, or even just the non-trivial (but still well-established) ones? How much knowledge about a programming language can you expect your collegues to have? How much can you expect them to learn?
My background is C++ programming. It's certainly not the easiest programming language to use or learn. And it's evolving. In an internal training, I was introducing my collegues to std::tr1::bind and std::tr1::mem_fn which will be part of the new C++0x standard (but are already available to us when using MSVC 2008 SP1 or the boost C++ library).
Let me show you an example to demonstrate my point:
I would expect a novice C++ programmer to understand the following piece of code. Assume _controls to be of type std::vector, which basically abstracts an array and which allows access to the items in the array via array[index].
void Controls::updateBay(IDeskPtr desk, IBayPtr selectedBay, ContainingBayInterface* containingBayInterface)
{
const unsigned long controlCount = _controls.size();
for(unsigned long index = 0; index < controlCount; ++index)
{
Control* control = _controls[index];
control->updateBay(desk, selectedBay, containingBayInterface);
}
}
Now our code usually looks like this:
void Controls::updateBay(IDeskPtr desk, IBayPtr selectedBay, ContainingBayInterface* containingBayInterface)
{
ControlCollection::iterator it = _controls.begin();
const ControlCollection::const_iterator end = _controls.end();
for( ; it != end; ++it)
{
Control* control = *it;
control->updateBay(desk, selectedBay, containingBayInterface);
}
}
This makes the code more general (_controls could be any collection type supporting iterators) and is generally understood by all our engineers, but it already assumes you know what an iterator is.
Now the new std::tr1::bind lets me write this code like this:
void Controls::updateBay(IDeskPtr desk, IBayPtr selectedBay, ContainingBayInterface* containingBayInterface)
{
std::for_each(_controls.begin(), _controls.end(), std::tr1::bind(&EmulationControl::updateBay, _1, desk, selectedBay, containingBayInterface));
}
Knowing about iterators is not enough any more. Now you need to know what for_each does and you need to know what bind does.
Everyone with a bit of programming experience understands what the first code example does. Some people claim the one-line for_each statement to be safer (or more efficient) but I'm not sure this is enough reason to prefer it over one of the hand-written loops. While I today prefer this kind of code, it's hard for me to explain why.
If someone wants to share her/his opinion, I would be very interested!
ak_:
As a crappy, dilettante coder, to me a code is beautiful when i can look at it after 2 months without saying "What the f*ck is that ?" :)
Eóin:
phitsc, to me the question of what knowledge of a language you can expect from others is a separate issue. Though of course a very important one in a team situation.
In your example the decision I'd be trying to make is between you third example or a similar 2 line version where the result of the bind is stored in a tr1::function. It's the trade off between the evil of introducing a redundant variable versus the evil that the single line version is too long.
phitsc:
In your example the decision I'd be trying to make is between you third example or a similar 2 line version where the result of the bind is stored in a tr1::function. It's the trade off between the evil of introducing a redundant variable versus the evil that the single line version is too long.
-Eóin (March 17, 2009, 02:32 PM)
--- End quote ---
I agree, we often do this (as you can see in my 2nd code example). Temporary variables are not only good to shorten lines and make complicated looking code look less complicated, they can also make it easier to debug. On the other hand, we get ever wider screens ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version