Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 636 posts at DZone. You can read more from them at their website. View Full User Profile

How to be a worse programmer

07.08.2010
| 58442 views |
  • submit to reddit

Lots of tips collections come up on DZone about how to become a better programmer. But no one ever told us how to become a worse one. What would make our colleagues and everyone who read our code violent? What can question their assumption and introduce defects under the hood of what they think cannot stop working?

I'm not talking about long-run quests like "read or don't read books about programming", but about practices that we apply in every day coding. You always have a choice: you can do the right thing, or becoming instantly a worse programmer by continuing doing what you know will slow down you (Uncle Bob). Here's a guide on how to pursue the latter hypothesis, hoping that it won't be followed by any of us...

The basic tips

The first round of tips is pretty simple: following this advice will result in a lower quality of your code without getting immediately noticed as a bad programmer.

  • Hardcode everything from file system paths to database connection params into the code, instead of providing a configuration file.
  • The maximum results with this approach are obtained with the hardcoding of magic values and their dependent values to make them untraceable: instead of writing N as the array size and N - 1 as the index of the last element, just write 10 and 9. When you change 10 to something else, fun will ensue.
  • Introduce many boolean arguments, especially when there is no support for named arguments like in the majority of programming languages: processThisList(list, true, false) is a line of maximum clarity.
  • Copy and paste the same code many times, and spread that logic all over ten or twenty files.
  • Use lots of arguments: start with three per method and add more.
  • Use the shortest variable names you can find: space shouldn't be wasted. A single letter is the better choice, with bonus points if you use i and j as global variables.
  • Better than using short names is using long similar names: percentage, percent, perCent at the same time.
  • Much better if the similarity is in semantic instead of form: score, points, grade, mark. All with subtle differences like data type or meanings like including a modifier (like a discount or bonus) or not. Pro tip: switch this meanings in different source files so that an Ubiquitous Language can't be extracted.
  • Spelling errors like initilize() are very good because make your code seem generated by a bad MDA tool. Especially if there's an unrelated initialize() methods in the same class.

Intermediate level

The intermediate level is composed by more dangerous practices, but that can still be workaround by other savy developers, resulting in the disruption of your efforts to make code incomprehensible.

  • Stop refactoring. We are covered by tests, so we can still do it later when we have time, right?
  • Start writing diagrams, then make them immediately out of sync with the code and publish them as documentation. Hope the next developer that comes across this documentation does not know your home address.
  • Insert business logic in the user interface without any separation of concerns, so that to reuse any method you'll have to instantiate a widget of the user interface (Magic Pushbutton).
  • Put all the methods you can think of in an interface the client code has to implement instead of using a bridge pattern. No one would even try to implement it, or will implement it with generated methods returning null.
  • Introduce accessed-in-all-the-codebase context objects that make the various classes using them very boring to test. To use a context object, scatter in the client class calls like: this.getContext().getOptions().getCategoryA().getCategoryB().toString().
  • Chekov's gun rule: if a gun is shown hanging on a wall in a scene, then that gun must go off in the rest of the movie/book. So set up a Chekov's gun in a hidden, far far away part of the execution path, and take advantage of this effort in a totally unrelated part of the codebase to introduce a plot twist (Action at the distance). The other developers will thank you for the emotions you gave them with your literary work source code.
  • never delete code: probably it would be difficult to checkout a tag from the source control system. Better to comment it out, or best, leave it in a method which isn't called anywhere (and a public one, so you can't immediately delete it as unreachable code).

The big cannons

These expert tips would rotten the codebase like anything else. Make sure you won't be responsible for maintaining it anymore in the future or they may backfire.

  • Stop writing tests. Jump back to cowboy coding and add features without knowing if they work, committing at random points to the repository.
  • Stop running tests. Since we are smart, the changes we made cannot have broken something.
  • If you still run tests, at least mix up different kind of test so that the slowest ones (acceptance/functional) take with them the fast ones (unit/integration), and the whole test suite must be executed every time you need some feedback.
  • Get rid of real unit test by instantiating at least two different classes in every unit test so that when it fails you won't know where to look. The more classes you throw in, the slower and difficult to check the test will be.
  • Similarly, instead of wiring up the different classes in the test so that it may be fixed in the future, you can hardcode new operators in the highest level class so that it instantiates its collaborators instead of asking for them (which would be the overhyped technique named Dependency Injection). More points if this is recursive, with these collaborators creating two database connections, opening a bunch of files and instantiating a payment gateway to pass it your mother-in-law credit card number in an assertion. So much for Command-Query separation: a new can blow up the whole world.
  • Put getters and setters on anything, even on services collaborators. This actually makes you able to change these collaborators in the middle of other code that uses the service object, with funny results for the poor fellow that will call the service after the change, basing on false assumptions.
  • extends is power. Everything can be subclassed to gain its functionality, by accuratingly studying the documentation and find out the class with more methods (it's a pity we usually don't have multiple inheritance.) This way, you can reach some hundred methods on your single God class, which will be the Facade of your software system.
Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Josh Marotti replied on Thu, 2010/07/08 - 8:54am

Great article, though I think it would be better to split it up into 3 separate articles of anti-tips with the tip, an explanation, and what to really do.


Also, I'd like to add (and I don't know which level):
Over-architect. 

  • Force everything to follow your architecture, even if it doesn't belong or fit
  • Solve problems you think will happen before you get all the logic in place (I think this part will be slow, so I'm going to start with it at maximum efficiency!)
  • Read your patterns book regularly, and see if you can make code that is nothing but design patterns!
I'm expecting a few people to hate on me for one or more of those points, but I've seen overarchitecture in more places that just bad code.  I believe in good architecture and I love design patterns, but I dislike projects that can't even get started because of either bickering over the architecture or so much overuse of architecture and design patterns, it takes 5 years to understand enough to code to it.  There can be too much of a good thing!

Giorgio Sironi replied on Thu, 2010/07/08 - 9:36am in response to: Josh Marotti

A problem with patterns is that generic design patterns are always considered, while analysis patterns are widely ignored. There is an entire book by Fowler explaining the various domain-specific patterns like how to model the classical hierarchy of person/employer/manager.

Paolo Denti replied on Fri, 2010/07/09 - 4:35am

Super fantastic article.

I would add the following points, as worst practices specific for web applications

  • instead of hard coding the sql queries in the code, read them from an http parameter; in such a case you can reuse the web page for generic sql execution.
  • put results from sql queries in session attributes instead of response attributes; therefore you can avoid hitting the db when reloading the same page.
  • implement a model 1 architecture splitting the logic between controller & view, for example putting the security in the servlet and the sql query in the jsp

Patricia Marchand replied on Fri, 2010/07/09 - 8:06am

Well I read your comments on how to be the 'worst programmer'. What is programming? I think we all forget that we code to create solutions, to solve problems. The coding is secondary to the preparation. Sometimes, and more often now, languages -such as .net- are very.... Hmm how to say... buggy! say the least, and one has to 'recreate' few functions just to bye pass those ugly problems. I have seen many times over programmer who forget themselves in their codes, and this is not a compliment, they tend to forget the target is to write an application which will make the clients happy (users or businesses) not to embark into a coding context.

Giorgio Sironi replied on Fri, 2010/07/09 - 10:00am in response to: Patricia Marchand

Code is the only model that counts in programming (processors do not execute diagrams), and there are movements like DDD who propose to center the development on the model of the business domain, which is the right choice for every non trivial application. The less infrastructure gets in the way (see old versions of EJB), the more can get done and make your clients happy: we do not write follow $practiceX and $practiceY because the resulting code is beautiful, we follow them because they keep the code fresh and ready to respond to new or changed requirements from customers.

Giorgio Sironi replied on Fri, 2010/07/09 - 10:02am in response to: Paolo Denti

Actually passing SQL query or query parts in the Url is one of the most evil pattern we can think of. :)

Collin Fagan replied on Fri, 2010/07/09 - 3:54pm

I've got a couple to add.

  • If memory footprint becomes a problem just start a thread that calls System.gc() every 5 seconds.
  • Never put functionality in a sub-class. Keep all the code 'centralized' in the base class and use instanceOf to decide which code path to execute.
  • No matter what, always implement your own sorting algorithms and name them something  indistinguishable from your shuffling algorithms.
  • I have one word my friend, static. It allows you to call anything from main and get back to using good old fashioned global variables.
  • Always adjust for daylight saving time by subtracting one hours worth of milliseconds from the actual value of the date. Also never bother to check whether the current timezone respects DST.
  • Who needs objects? HashMaps get the job done!
  • Always use reflection when some stupid programmer decided to make something 'private'. Reflection can also help work around the stupid restriction that strings are 'final'.
  • Make sure to implement finalize in every class. Setting all members to null will help "free up" memory.
Thease would all be really funny... if I hadn't had to actually work with the people who did them.

Collin

Eran Harel replied on Sat, 2010/07/10 - 8:10am

Just as Colin stated - the saddest thing about this article is that you will always find these 'best practices' hiding in your code base, and there will always be a dinosaur around to explain why the code had to be implemented this way.
 
I've seen each and every one of these tips. The main problem is that the dudes responsible for this mess are masters of obfuscation, and you always find more surprises when you try to refactor their code and make some sense of it. The only way out is usually a complete rewrite.
 
Perhaps one day we will all be craftsmen and we will no longer have the need for this sort of bitter articles.

Gilbert Herschberger replied on Sat, 2010/07/10 - 1:19pm

What is a dinosaur? A big, powerful animal with a brain the size of a pea. Old and extinct. I want to hear more about how to be a dinosaur programmer.

A few years ago, I met a worse programmer. I was working steadily on a project, minding my own business, modernizing an application with about 100 forms. He starts bragging about how he can do in 30 days what has taken me two years to accomplish. He claimed that he could build all 100 forms with some new technology. It would solve all problems quickly and easily, without any need to ask the end-users what they want.

I strongly encouraged management to give him exactly what he wanted. Unlimited support for his idea for 30 days. Whatever he requested, we delivered. He wanted a brand new PC; he got it. He wanted a high definition monitor; he got it. He wanted expensive software; he got it. At the end of 30 days, how many forms do you think he delivered? Zero. None. Nada.

At the end of 30 days, I went back to doing what I do well, give people what they want. I gave him what he wanted. He wanted an opportunity to prove that he was a better programmer. Enough said.

Post script: After posting my comment, I just realized that there is one thing that he never bothered to ask for. He never asked for information on the existing system. Puzzling, isn't it?

Makah Rratt replied on Tue, 2010/07/27 - 9:59am

never delete code: probably it would be difficult to checkout a tag from the source control system. Better to comment it out, or best, leave it in a method which isn't called anywhere (and a public one, so you can't immediately delete it as unreachable code).

This is bad

John Hyde replied on Tue, 2010/08/17 - 9:42am

Still my favourite technique was the work of a contractor employed at an insurance company to optimise their mainframe COBOL programs. He worked solidly on all the available code for a week before another developer noticed that he was just going through and deleting all the comments from every module. Which might have even had a miniscule effect if COBOL wasn't a compiled language.

Shaun Powell replied on Tue, 2010/08/17 - 11:49am

More fun tips:

  • While loops should run forever, so encapsulate everything including the condition variable or make sure to always be true to your while loops. If all else fails, use a break and goto
  • For loops can go backwards too. It's always good to nest contrasting loops together, as your fellow colleagues will find it great fun to fix your code mazes
  • AJAX call everything, as constant validation is key, but make sure to be extra helpful and clear all the user text field of content whenever they make a mistake. Viewstate only bogs down the network anyway.
  • Indenting is for whimps, and why not code that whole function into just one line of javascript.
  • That global i variable in the gac was very useful for passing around the index value between classes.
  • Who says you can't cast a decimal into a double?
  • Don't forget to null that string. No one wouldn't be expecting that!
  • You may not be able to multi inherit everything, but you sure can interface it all! Who needs polymorphism? Just duplicate the same code over different classes with the same interface.
  • Remember, you can overload your constructor with all the same signatures types but in different orders
  • If you have 30 properties in a single class; you don't have enough
  • Classes can get cold and lonely, so couple them together and throw a class party! No secrets here; make everything public accessible, and if you don't like the calls you see, you can always override them
  • Finally, once you are happy with all the code you have written and tested for the past 3-5 years, you lastly remember to fit the comments and documentation, if your memory serves you correctly. It's your code, so who else knows better about it than you do anyway?

Instant Tax Sol... replied on Thu, 2011/08/04 - 10:57am

A worst programmers tend to not buy into the project emotionally, intellectually and professionally. They tend to show up, do the bare minimum to get by, and then leave. -Instant Tax Solutions

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.