How to deal with seniors' bad coding style/practices?

Question

I am new to work but the company I work in hires a lot of non-comp-science people who are smart enough to get the work done (complex) but lack the style and practices that should help other people read their code.

For example they adopt C++ but still use C-like 3 page functions which drives new folks nuts when they try to read that. Also we feel very risky changing it as it's never easy to be sure we are not breaking something.

Now, I am involved in the project with these guys and I can't change the entire code base myself or design so that code looks good, what can I do in this situation?

PS> we actually have 3 page functions & because we do not have a concept of design, all we can do is assume what they might have thought as there is no way to know why is it designed the way it is.

I am not complaining.I am asking for suggestion,already reading some books to solve the issues Pragmatic Programmer; Design portion from B.Stroustrup; Programming and principles by B.Stroustrup;

Answer 1

The best and most important thing you can do is lead by example. Do things the right way and try to improve things slowly. You aren't going to fix anything overnight.

Make sure every piece of code that you are responsible for is better after you are done with it. Over time, the system will tangibly be better because of your efforts.

After you build a strong reputation with your co-workers, try go start some code reviews or lunch-training sessions to get everyone up to speed on better ways to do things.

In a nutshell: it will be difficult and frustrating, but it's possible. Good luck.

Answer 2

If you're a junior dev, then the only thing you can really do is write code as elegantly and readable as possible.

If your style is indeed better, other people might notice and say "hey we should adopt this formula"

Actions speak louder than complaints, which is something I noticed.

Answer 3

This is how it is, get used to it or quit and find a place where it isn't like that. You will be marginalized if you criticize their efforts and they may feel threatened if you do indeed write your own, better code or improve theirs. At the end of the day they deliver code and management sees a black box that works and that's all that matters. Plus, you'll be just another kid from college who thinks he knows something about development at a business and laughed at and ostracized when not around. Honestly, a lot of the times these systems are built like this because of shaky requirements, lots of functionality bolted on with time and managements lack of respect for a stable software development process.

Not all companies are like this. I'd start looking for a new job to be honest.

Answer 4

Being enthusiastic to code the right way is a good trait to possess and in the software industry we will always encounter other developers who write code that is not quite in line with our "perfect way" of coding. This should never be interpreted as rubbish code, or inept coders, because we all start out like that in some shape or form.

Always respect your peers around you as you want them to respect you. It's certainly not easy to do in an environment that highly regards ego, but attempting to approach a topic like this is never easy.

It's how you communicate

Try different approach angles, remember you are there to learn as much as to render a service.

So commenting on the "poor" code style in an "in-your-face" kind of approach might not be the result you were looking for. So then back up a bit and try approaching the topic with "I was considering the style of code used and have a few suggestions..." and see the difference that gives.

Where I work now, the one thing I've learnt is that it's fine to comment on something that's might not be good quality but then I had better have a better solution to present.

In other words, be prepared to back up your words with useful solutions and not because you feel so.

Answer 5

I fervently hope, this is the best opportunity to grow by facing the challenge.As Robert said,try to lead by example.If possible let them adopt your pattern.

Answer 6

Your best bet is to NOT to handle it at all. Here are potential problems if you try:

1. You will be criticized for doing something you were not told to (makes performance reviews go real bad.)
2. You will have less time to do your own work.
3. You will not advance your career by cleaning working code- if it is not broke then do not touch it.
4. Never make enemies with people who control your career- unintentionally implying they are obsolete morons does not help your cause (especially in a bad economy).

Focus on making your own code great. Battling poorly written code is part of the ill of being a Software Engineer. You are in the wrong profession if you will not stand for it.

A little off point but important- You may need to switch jobs or teams if possible once the economy picks up. Mixing with a truckload of bad coders who do not bother to update their knowledge and practices dulls your own programming skills and weakens your marketability.

Answer 7

The present is embodied in Hexagram 47 - K'un (Oppression): Despite exhaustion, there may yet be progress and success. For the firm and correct, the really great man, there will be good fortune. He will fall into no error. If he make speeches, his words cannot be made good.

The future is embodied in Hexagram 6 - Sung (Conflict): Though there is sincerity in one's contention, he will yet meet with opposition and obstruction. If he cherish an apprehensive caution, there will be good fortune. If he prosecute the contention to the bitter end, there will be evil. It will be advantageous to see the great man. It will not be advantageous to cross the great stream.

Answer 8

This is the most basic reason why establishing coding standards and code review processes are a good idea.

I will not write three page functions no matter what coding standards and processes are established, but some people will. They will create 20 local variables at the beginning, without initializing any of them. You'll have pointers and integers with unspecified values. You won't know the exact meaning and scope of each variable. Etc etc.

Try to convince your manager and, later, your team, with solid arguments. Maybe you could start with a shared reading of Effective C++ or C++ Coding Standards. Try to stress the point that, when working this way and creating better code, everybody wins. If they see this as a win-win situation, they will be more open to the change.

Answer 9

You are not alone. I too faced recently, luckily we have support from Senior Management for Code Reviews. 1. Even a single line change for Bug fix should be reviewed online.

1. Comments on code can be classified as CodingStandard/Suggestion/Clarification/Major/Minor etc

2. While giving comments to senior you can start with Clarification/CodingStandard rather than Major

Answer 10

I can empathize.

I'm below two senior programmers who have very unique styles that I find frustrating. We have code that consists of one main function that's 1000 lines long. (That is not a typo.) Our coding standards discourage globals, so we make every program one App object. Now our globals are member variables! When we need an iteration interface for C++ classes, why should we use the begin, end, and operator++ conventions, when First, AtLast, and Next can be used instead. We've wrapped up third party libraries in custom interfaces for no good reason. (We've wrapped log4cxx and lost functionality for no reason I can tell, and one of our date classes consists of a shared pointer to a boost::date object with a fraction of the functionality.)

Here's how I've kept my sanity. I've focused on the new languages and tools. This is our company's first project involving Python, and I've spent my time writing utilities and programs there. While the senior programmers code in what they're familiar with, I've got near free rein of all the Python code. I couldn't stand the C++ APIs we use, so I duplicated most of the same functionality in Python in a much more friendly way, and the other developers prefer it too.

Likewise, we have little familiarity with log4cxx and less with boost-build, both of which I've taken time to study in depth and know good enough that people come to me with questions. I've written a handful of resources on our wiki giving usage tips for log4cxx and numpy and other tools.

Answer 11

You could address the issue of "we are afraid to touch it for fear of breaking it" by writing extensive unit tests. Once you get the unit tests in place, you will be freed to refactor at will. If your unit tests still pass after the refactoring, you can be confident you haven't broken anything.

Answer 12

I was in the exact same shoes before. I got hired as a C++ programmer to 'lead the team' on how to use C++ by an enthusiastic manager. That was about a decade ago. Some of the newer engineers loved me, the seniors despised me. Our system was basically a pseudo-C++ system. It was like C with classes, but it appeared that people didn't even understand the usefulness of things like constructors since they hardly appeared.

You complain about functions that are 3 pages long; we had functions that were 8000 lines long full of long jumps, function pointer casts, etc. One of the seniors even formatted the code with 2-space indentations so that super deep nested blocks can be written without using much horizontal space since the seniors seemed to be allergic to writing functions and procedural programming in general. Someone even inlined a 2000 line function thinking it would make things faster. You might be dealing with some bad code, but I was dealing with the most horrid copy-and-paste code imaginable.

Unfortunately I was very young and cocky. I didn't get along with the seniors, I fought against them in territorial battles over code. They responded by creating coding standards which no sane C++ programmer could follow (ex: it's okay to use operator new, but don't use exception handling, don't use constructors or destructors, etc). As a result I wrote the most bizarre and stupid standards-workaround C++ code just to kind of rebel against those standards since I refused to write C-style code given the reason I was hired (I didn't hate C so much, but writing C code was not part of the job description: I was hired essentially as a C++ consultant), even though the standards made C-style coding the only practical way to do things. I only kept my job because I put in so much overtime to make sure that my code works very well in spite of these ridiculous coding standards.

It wasn't until years later when others started to see things my way that we lifted the silly standards and started writing more natural, easy-to-read C++ code complete with STL and boost goodies, RAII, exception-handling, etc. That isolated the seniors who refused to write code in a more sane fashion and they were finally forced to adapt.

In retrospect, I could have done things much better. The seniors were intent not to allow me to be put in a teaching position, but I think I would have gotten my point across much faster with my head down. The biggest regret I have is trying to work around the impossible coding standards rebelliously rather than getting them rectified through clear and rational discussions. As a result, I have really stupid and obfuscated C++ code in the system which people attribute to me even though that's not how I normally write C++ code. The regular developers I work with understand this, but the seniors still point to it as an example of why C++ is bad.

In short, I recommend that you focus on making more friends rather than enemies. Your friends will support you, and if your way is better and you can clearly demonstrate it, you can isolate the few who will never agree.

Answer 13

Just place a copy of "Clean Code" (Martin), "Refactoring: Improving the Design of Existing Code" (Fowler) or "Effective C++" somewhere in the office where people may start browsing the books. From now on, word will spread. Seriously, its never too late to learn! ;)