I work with a lot of legacy Java and RPG code on an internal company application. As you might expect, a lot of the code is written in many different styles, and often is difficult to read because of poorly named variables, inconsistent formatting, and contradictory comments (if they're there at all).

Also, a good amount of code is not robust. Many times code is pushed to production quickly by the more experienced programmers, while code by newer programmers is held back by "code reviews" that IMO are unsatisfactory. (They usually take the form of, "It works, must be ok," than a serious critique of the code.) We have a fair number of production issues, which I feel could be lessened by giving more thought to the original design and testing.

I have been working for this company for about 4 months, and have been complimented on my coding style a couple of times. My manager is also a fan of cleaner coding than is the norm. Is it my place to try to push for better style and better defensive coding, or should I simply code in the best way I can, and hope that my example will help others see how cleaner, more robust code (as well as aggressive refactoring) will result in less debugging and change time?

  • Better implement Scrum somehow. It will make everybody's life easier. – PradeepGB Dec 5 '10 at 5:39
  • 1
    Try to find good tools that can examine code and make complaints/recommendations - that way it will not be personal. Finding a free tool would help to sell the tool to others faster. – Job Dec 5 '10 at 16:11
  • @PradeepGB - They can't write clean code. First things first. – JeffO Mar 10 '16 at 22:42

You didn't mention your level of expertise on the subject. If you are not a senior programmer however, I think the best thing you can do is to do your own work well. You also mentioned that your manager likes clean work - that's great. If you can talk to him about it (maybe in a semi-professional environment) you should share your concerns about the issue with him. HE is in the position to change workflow.

  • 4
    +1: If you're in the trenches, the worst thing you can do is spend time throwing down on your coworkers. You can broach the subject your boss, and leave it to him to push the change. That's his job. – Satanicpuppy Dec 5 '10 at 1:59
  • 3
    If you write clean and easily maintainable code then it will stand out, especially if your boss is aware of the benefits of that. If your code runs faster or is more robust then you'll stand out also. Either will make your case for you. – the Tin Man Dec 5 '10 at 7:40

What does clean code mean for you?

I'm sure your definition is great, but the other guys in your workplace probably have their own definition. They are not wrong, only different from yours.

You should create coding guidelines which everyone in your workplace can agree on, and you should do it together with your fellow programmers. Don't try forcing this on people, it will backfire if you do.

So get the team together and start working on a common definition of "clean code"! There are no hard rules to this. You are trying to bringing several minds together and that can result in conflicts, so you may want to set the stage with a positive note that you all should be respectful and keep an open mind (code writing is personal...).

The Clean Code book may come in handy. You could use examples from that book to talk about and see if you find some common ground in there?

  • +1 - I would argue that it's usually better to put a set of coding standards together before addressing the problem, so you come to the table with a solution in hand that your co-workers can start with. Leave in the parts that everyone agrees with, add whatever may be missing. – Tim Post Jan 30 '11 at 10:20

There are two things which can do wonders for ensuring a a consistent and high-bar for code quality.

Do Code Reviews

You should strive for every checkin -- no matter how trivial -- getting reviewed by another person on the team. No exceptions. This seems like it will get in the way at first, especially for senior developers who think they don't have anything to gain by having less experienced people review their code. However, having regular code reviews will have an immeasurable impact for every developer on the team.

Define a Standard and Stick With it

At Google we have a coding style guide for every language we use: C++, Java, Python, etc. While engineers are free to disagree with the style guide, it is not optional. (And is rigorously enforced in code reviews.) As a result, the entire codebase -- hundreds of thousands of lines of code -- is very consistent.

  • 1
    The general problem is that google has, and pays for, a different type of programmer than the typical fortune 500 does, especially if IT is seen as a cost center. Google's solutions may not work at a pharmaceutical company. – Christopher Mahan Dec 6 '10 at 7:29
  • Why every commit? Reviewing every commit seems unnecessary and potentially problematic - a 'control' focus rather than a 'culture' focus. It risks low quality or non-existent review and discussion becoming normal. Also, a good level of autonomy is important to wellbeing and retention and a sense of ownership. Picking limited code fragments at random and reviewing it well shouldn't be ruled out. It'll get people thinking and talking about code quality. It needn't be rushed to get through everything - and it'll still bring about knowledge transfer. – Alex Hayward May 12 '19 at 17:06

I think that if you are passionate about clean code then this will rub off on your colleagues. The "It works, must be ok" mentality that can be changed by people that advocate good design and clean code in a enthusiastic way.


Though several useful answers have been posted here for awhile, I believe there is room for one more. My suggestion is, as others have said, to do code reviews. But it is worth mentioning again because the term "code review" is so vague... almost as vague as "clean code" :-). I have spent a lot of time and effort myself in working toward that elusive goal. And particularly in the last couple years, fueled by colleagues who shared my passion, I distilled my notions, blended with key ideas from prominent developers, into a series entitled the Zen of Code Reviews.

My articles are unique, so far as I know, in that I cover both sides of the aisle: doing a code review as an author and doing a code review as a reviewer. Though related, the skills for each are somewhat different. And being able to do both well will lead to better code quality. Reviewing code is just as important as writing code. Really. It promotes knowledge transfer, it encourages team consistency and communication, it helps you improve your craft, and last but not least, it reduces buggy software very cost effectively--from as close to inception as possible.

The first two provide tips and techniques for preparing a code review. In a nutshell:

  • You as the author have intimate knowledge of why each changed line is in your code review. Many are obvious to an educated reviewer, but many are not. Convey those points by annotating your code review before you send it out to reviewers.
  • Even before that, consider carefully what comprises your code review: make sure you include all relevant changes for an issue and try not to include more than one issue.
  • Make sure you do a source control checkout (to resync your code with main) before you send it.
  • Review your own code before you send it--line by line!

Part 1: Pre-Review Comments: Empower your colleagues to give you better feedback on your code review

Part 2: Best Practices: Guidelines for preparing a code review

And the other two articles provide practical advice on how to be a better reviewer:

  • Read the Jira/issue/ticket/requirement (whatever you call it) first.
  • Ensure the unit tests cover the requirements.
  • Review the unit tests for equivalence class and boundary value completeness.
  • Ensure each unit test does just enough, not testing multiple things.
  • Review the code for adherence to SOLID principles.
  • Watch out for re-inventing wheels, over-complicated code, and just complicated code.
  • Eschew magic (magic strings, magic ints, and, yes, even magic booleans).
  • Catch the butterfly effect--are there ripples that were missed (e.g. naming inconsistencies).

Part 3: The Reviewer's Tale: Guidelines for performing a code review

Part 4: Review As If You Own the Code


Lead by example. Have your code reviewed.


In my experience most "RPG + Java" applications are written by programmers coming from the RPG side, and not from the Java side, and the mindset of the two worlds are very different which I believe is one of the reasons that you have basic design problems.

The official IBM tooling is Eclipse-based, so if you use that, you can use most of the tips and tricks available to Eclipse, and you need to find things that give much in return for little effort, because basically you need to show these folks that it is worth doing at all.

One of the most efficient things I have found for this, is the Save Actions of the Java editor, where you can ask it to reformat your source every time you save a file. This will in a short while result in a more uniform coding layout making things easier to read. I wrote up my findings here.

If first you have the notion planted that you may have useful suggestions people are much more likely to listen...


"Everyone writes bad code". Digest it and then acknowledge it. This sets the entire team in one plane that breaks the hierarchy and instills in everyone that all are equal. It is very important for a senior programmer to demonstrate these behavior and attitude. With these as premises, practice pair programming during which you should discuss, debate (time-boxed) and converge to a decision on what is right after conversing why something thing could be wrong. While pair programming one person is superior over other - both are humble and open programmers. What better way to promote good coding practices! :)


One way I haven't seen mentioned in any of the answers so far is education. Get your company to sponsor entry for those who want to go to your nearest JavaZone or RubyConf or whatever conference is suitable and convenient for you. Find courses that are relevant and send selected developers to attend. If your company is big enough, it may even be feasible to arrange internal seminars and courses on subjects like best practices, master classes for your language etc. Get a good lecturer on the subject and prepare a course that's tailored to your company's situation.

My company is doing this quite a lot, and while there's still those who stubbornly refuses to be interested, the overall awareness of issues like these are growing – and the general state of our code base is improving. Even the "Basic C" course we did for several rounds proved to be enlightening to developers who have been writing C for as many as 10-15 years. Not because they're bad programmers, but because you tend to fall into habits and forget why, and that the language and the collective experience about how to use it is slowly changing too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.