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
  • 2
    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
  • @Job There are tools to accomplish that outside of VS / ReSharper? I haven't heard of it yet but would be interested to know. Does this kind of software bear a name I can easily find results about on Google or such?
    – jeromej
    Apr 27 '21 at 14:55

12 Answers 12


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.

  • 7
    +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. Dec 5 '10 at 1:59
  • 4
    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. 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?

  • 2
    +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.

  • 2
    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. 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. May 12 '19 at 17:06

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

  • As an example: “Make sure every unit test does just one thing”. So what? A unit test testing twenty things won’t cause any problems. If it asserts you fix a problem and run the unit test again. That’s the kind of thing where you lose all your bonus points.
    – gnasher729
    Apr 29 '21 at 17:23

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.

  • It works with some people but in my personal experience, that was often not the case. Maybe there need to be some specific selection based on some criteria when new developers are hired to ensure the likeliness of this kind of mentality.
    – jeromej
    Apr 27 '21 at 15:09

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...

  • More uniform layout doesn’t make things easier to read. Readable layout does. A tool making layout changes while I’m not looking is just awful.
    – gnasher729
    Apr 29 '21 at 17:26

"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.

  • Great advice. Make the junior developer send selected developers to courses.
    – gnasher729
    Apr 29 '21 at 17:27

My advice is do lead by example, practice it yourself, try being subtle about it, approach the problem calmly and try to make them see all the good bits that clean code can bring, show it yourself, or make them read other people's code, maybe they will realize it by themselves, and if by any means you notice that they will not do it out of laziness and the situation became a problem, reach out to your manager.


In practice, the highest priority is getting the job done :-(

As a junior developer you have the luxury that you won’t be held responsible for a shipping date. Others don’t have that luxury. Anything you add is just taken as a bonus.

Look very carefully if that is what is happening. If someone works overtime to meet a shipping date, they will not be pleased if someone tells them that their code is dirty and they should work more overtime to please the junior developer.


As a (hopefully interesting) side note,

You're mentioning clean code but, especially regarding big/growing companies with a lot of code/legacy/developers, there is a level above clean code.

While clean code is good/important. So is "architecture". Clean code would be like nice bricks but you still need an architect to know how best to assemble them and the rooms to fit a global architecture.

One way to promote that can be to hire someone specialized in that, called an architect. Usually a clean architecture also promotes cleaner code more easily. So win win.

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.