I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Clean Code: What Advice Would You Give To Novice Programmers?

10.05.2010
| 8199 views |
  • submit to reddit

I'm a big fan of the 97 Things series. Rather than depending on one author to be an expert on a particular topic, everyone gets together to pass on their own real world experience. I'd like to give this crowdsourcing approach a go in this article to gather all the advice that you would pass on to novice developers. With students started in their university courses, it's the perfect time to gather your thoughts.

To get things going, here are a few of my own thoughts: 

Test Driven Development Really Is Worth It

Whether you take the purist view that you need to have a failing test first, or you simply consider what tests you will write straight after the code, having your test cycle tightly coupled to your coding process makes your life easier. Less bugs will come back, and most importantly, you'll think more critically about what you're going to write. Anytime that I've seen test driven development in practice, it's helped quality. The sooner you get used to the process the better. 

Don't Rely On Comments Too Much: Make Your Code Self-Explanatory 

Don't get me wrong here, comments are great. But you don't really need to put comments around the getters and setters. You should apply that methodology to standard methods too. Make the method name as explanatory as possible (without being too verbose), and add comments to describe only what the caller really needs to know. It's a delicate balance, but you'll get used to it. 

Don't Let Exceptions Disappear Into A Black Hole 

Checked exceptions exist for a reason. As a result of the code completion functionality provided by most IDEs you can easily add a try/catch around a block of code. There's nothing worse than seeing the default //TODO in the catch statement.  Other times you will see that the exception is simply printed to the console (not even logged). This all seems like another purist view, but when you're trying to find the cause of a particular bug and find that the exception which should have been thrown to the caller was simply ignored, you'll see why it's important to treat exceptions with the respect they deserve.

 

 

Tags:

Comments

Josh Marotti replied on Tue, 2010/10/05 - 1:29pm

Don't reinvent the wheel.  Look at apache commons for solutions before home-brewing your own!

 

Annotations cause coupling unless the annotation is in the J2SE JDK.  Realize this before putting them in something you plan to reuse.


Code like you will reuse the code for other projects.  When you do that you end up reusing code a lot more often!

 

Look at good open source projects, especially API's like Spring and apache projects.  Learn what good design should look like an emulate it until you see why it is good design (and what you dislike about it). 

 

Argue with designers and architects, but keep an open mind and realize when you are wrong (but stick to your guns when you are right).

Esko Luontola replied on Tue, 2010/10/05 - 1:56pm

Avoid global mutable state, such as static variables and static singletons.
http://misko.hevery.com/2008/11/11/clean-code-talks-dependency-injection/
http://misko.hevery.com/2008/11/21/clean-code-talks-global-state-and-singletons/

Make your methods small and well named.
http://c2.com/ppr/wiki/WikiPagesAboutRefactoring/ComposedMethod.html
http://tottinge.blogsome.com/meaningfulnames/

Simple Design
http://jamesshore.com/Agile-Book/simple_design.html

SOLID
http://en.wikipedia.org/wiki/Solid_(object-oriented_design)
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Fab Mars replied on Tue, 2010/10/05 - 4:01pm

@Josh, I concur, totally.

As for myself, I'd just recommand to keep it simple.

Too many newbies like to over-engineer just to pretend to be smart or having fun with resume-driven-development. In other words, implementing every pattern in the book or putting bayesian filters in every corner of the code should be avoided if they aren't needed. Debugging, testing, maintenance will be all easier, not mentioning performance.

Anyway nobody knows what will be the next changes your customer will ask, so the best is to do what's necessary of course; and stick to what's what's sufficient, for the time being.

Robin Bygrave replied on Tue, 2010/10/05 - 9:33pm

Probably No.1 is that Newbies need frequent code reviews - reading is not enough.

 You can list code smells (Class too big, method too big, method with too many arguments, Ask don't Tell etc) but unless you are throwing away their code you need to review it frequently (and time for the reviewing/peer programming needs to be allocated and expected).

Ankur Gupta replied on Tue, 2010/10/05 - 10:29pm

@ Robin - completely agree and hence we enforce standards by using checkstyle / PMD, cobertura / emma, findbugs, etc within maven build cycle to make sure code in repository is adhering to a certain quality standard.

 Quality standard of course we configure from a project to project depending on requirements of course. Eg sometimes, a checkstyle violation may be an error (results in build failure - before commit) where as same violation on a different project might be a warning (results in build passing with warnings on build logs - before commit).

Karl Peterbauer replied on Wed, 2010/10/06 - 2:10am

Ageless advice from the Linux kernel coding style:

Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well.

Alessandro Santini replied on Wed, 2010/10/06 - 7:29am

1) Test, test, test.

2) The cleanest code is the one that will never be written

3) You will see how many times you will have to tradeoff between design and schedule. Forgive yourself but remember to refactor whenever possible.

Mario Gleichmann replied on Thu, 2010/10/07 - 9:31am

Another (Meta-)Advice: Even with a bunch of good advices at your hand - DON'T TURN OFF YOUR BRAIN!

Comment viewing options

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