Oh, come on, don't you agree, dear reader, that the code is the product of your work? And as something you produce, it's a damn reflection of yourself? Yeah, it's strange, but as in arts or even when you're blogging, you're tipping the world a little bit about yourself. If your code lack quality and that fine treatment, what image do you form from your fellow programmer? Laziness, lack of communication skills, lack of principles and even neglect.
Am I weird or what!?Do you remember GOTO? (Don't scream in panic please! You have my honor if you're an assembly programmer). Well... luckily :) if you're not, probably you don't use GOTO for years. I like Perl, well, I love Perl.... oh right, I would exchange a hand for an opportunity of programming Perl in Slashdot (cool!) and it's one of the programming languages I've most programmed in my life. But I bloddy don't know how to use a GOTO in the damn language!
What do I mean with that? Check it out: once an experienced programmer has stated: "Yeah, junior, put quality in your work. Never use GOTO. I'll scream on you if I find a GOTO when reviewing your code!" and that followed like that:
[Me]: "Oh, sure, it's one of my principles when I'm working. I think I've never used a GOTO in the last bunch of years"
[The fella']: "Ah ha! But you'll see when our customer is screaming in your back and you have to deliver that code during that dawn." [slow motion for the voice, please] "He-he-he-he-he"
Again, I've felt like an ET! What do my boss think when I say 'Code quality is my priority'? What do my fellow think of it? It looks like he appreciates quality, luckily, but when it comes to an extreme situation, he signaled that he sacrifices it!
Well, I'm really not questioning the quality of his work. Actually, he works in one of the most critical part of the system, so ho should be a very experienced programmer. But when it comes to an extreme situation, quality is sacrificed.
An analogyCan you answer why we have so many computer systems crashing and so few bridges collapsing? Or so few hardware failing? [Hey, Breno, if you're reading, tell me!]. Well, one of the raw "ingredients" that form a bridge is concrete (cement and some stones). Have you ever found a constructor telling:
"Oh, I'll put more water here and little bit less stone so we'll have more material!"
or an engineer stating
"The bridge design map?! For what? For storing it in the drawer after the project conclusion!?"
Man, that's quality. Those kind of workers don't lack quality in their work. They deal with lives. If the bridge collapse, it's the engineer laziness that killed the people.
Why would you, fella', not put quality in your code? Keep reading...
What is quality?Well, in my opinion, what is quality? Simply stating, quality as I've ever seen is:
- Enough documentation: please, think about the next devil that will sit in your chair and face your code. Some docs about the system design, the purpose of your packages or your intentions about dominating the World would be great, wouldn't they?
- Comments: please, let me know what is inside your head. If you take more than 5 seconds to think about your chunk of code, it's not trivial. Comment it!
- Indenting: please, be organized and indent your code. If you're a Python programmer, the compiler if your friend.
- Good architecture: maybe you think it doesn't matter now, but in the future, the [bad,lack of] architecture will destroy the system. If problems arise and the cost to fix them is giant because they don't deserve a quick fix, the deserve a really deep change in a damn lot of code: that's an architectural problem.
- Thinking about the future: will your system scale? Will the number of users grow? Will the network bandwidth be greater and more data will be flowing through your system pipes?
- Say no to repetition: please, be structured. Don't repeat code, use private functions, use helper procedures, common modules, constants. PLEASE, DON'T HARDCODE VALUES!
- Good object orientation (or structured) practices: it may look weird, but I've already seen people dealing with Java [or insert your object oriented programming language here] that didn't know what polymorfism, overloading, clever exception treatment, etc. When I'm working with something, I always try to get to know deeply the theory about what I'm working with. Otherwise, my knowledge will become superficial and soon or later my boss will kick my ass! ;)
- Know deeply your problem: give your problem some of your synapses before coding. Read about it. Look for a library that do what you're trying to do, discuss it with someone. Draft it before heavily coding.
- Test, 1 2 3: maybe you're hired as a "System analyst", "Senior programmer" or even a "Twitter System Engineer - Systems". Yeah, in your role the word TESTER doesn't appear. (I'll scream, like in PL/SQL code)BUT THAT DOESN'T MEAN YOU SHOULD NOT TEST YOUR CODE. [Juan, I owe you a beer or a chocolate box for that!]: please, create automatic unit tests, test your code, write about your tests and tell your boss that your damn code has been testes before the test team put their hands on it! Yeah, that's quality.
- [DEBUG]: Log, please: BubbleLog.Warn ("Please, be verbose about what is happening inside your code");
- Make clear code: please, write beautiful code! As in arts, you have the tools and the techniques, so express yourself and create a good looking painting.
One of the [real] guys I most admire, a fellow from university, is a damn good programmer and a bloody smart person. Man, he's code is a charm. Once I've asked him for a project we've had already delivered, just to see how fu**ing lazy I was. Clear code, smart comments, good object orientation practices. I'll post something from him in the next few days, you'll get amazed ;)
Too much bla-bla-blaI know, so read these concrete tips; that's what inspired me to write this post.
And look these guys from Coding Horror: in their article they cite:
The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it's not whether they prefer Python or Java. It's whether they can communicate their ideas. By persuading other people, they get leverage. By writing clear comments and technical specs, they let other programmers understand their code, which means other programmers can use and work with their code instead of rewriting it. Absent this, their code is worthless.
That's Joel Spolsky, one of the Stack Overflow founders.