I'm continually unimpressed by a certain form of argument that I've seen in many places, but especially in the continuing discussions about closures in Java.
It goes like this: Feature X is great, and will make lots of code simpler, but there will be a lot of worse code because of it. Sometimes co-workers are mentioned, sometimes contractors who have to maintain the code without having months to learn its innards.
I think this boils down to two issues:
1. *I* would write bad code with Feature X.
2. I'm worried that I'll have to deal with bad code that uses Feature X.
Any healthy programming environment will not freeze code that is known to be bad in some way. It can be fixed, and lessons can be learned. If you seriously worry about your co-workers, watch their commits. If you worry about yourself, write some non-critical code that uses the feature a lot; perhaps a prototype, some unit tests or something unrelated to work.
With some exceptions, most programmers will write bad code before they learn how to write good code. Let them do so, and help them to get past it.
My co-workers would get it.
6 comments:
Programmers will write bad code regardless what less facility assisting to that. Programmers can not write good code if not enough facility is provided. Thus, there must be a balance, which, IMHO, Java is too far away from.
I both agree and disagree. When the programmers making mistakes and learning are highly skilled and are passionate about their work, then yes, I see no harm in learning to most effectively use the features of a language.
When the programmers are dispassionate and pretty reckless (as I have had to deal with from some offshore environments), then I'd say some new language features can be near suicidal.
It's almost as if we need to consider two classes of language: those that will withstand the hackery of dispassionate and reckless coders, and those that offer passionate coders a chance to add real finesse and beauty to their code.
I think there's a third:
(3) I'd really like to use this feature, but slowly gouging my eyes out with a dull pencil sounds more pleasant than explaining it to some of my coworkers.
The dreaded coworkers need not be programmers. Managers and "architects" are often the worst.
To be truthful, if my co-worker is going to write bad code -- and it's not like a new feature will make him suddenly write bad code -- then I'd rather his bad code is 10-lines long than 100-lines long. That's less code to read, less code to rewrite.
@Daniel - LOL...good point.
This is one of my peeves. If your coworker is incapable of learning "Feature X", you a have bigger problem than "Feature X".
I'm pretty sure the workaround for not having "Feature X" is even more cumbersome and difficult to understand
Post a Comment