Csdrhrt

There is a senior software developer that I'm really not sure how he got there. But the style of coding is very bad. For example he has this scattered all over the project.

public boolean myMethod()

{

   if(somethingIsTrue==true)

   {

       return true;

   }

   else

   {

       return false;

   }

}

I know it's him because he has his initial with every one of them. And this is just a tip of a huge iceberg.

So my question is, what's the best way to deal with this situation/colleague? I'm trying my best not to offend him.

The sample provided shows that whoever wrote that piece of code does not understand how programing works. He does not understand basic data types and basic instructions. (PS: I created real-time embedded software for cars and for robots in the semiconductor industry for more than 15 years, so I know what I talk about)

Coding style usually refers to layout and indentation, but useless verbosity and inefficiency can also be considered "bad coding style".

That guy needs to be trained from basic level of programming, in whatever language. Otherwise, he will hurt the project (and the rest of the team) a lot.

Combined with the fact that he is a senior developer, there not only a red flag about this guy, but also an entire field full of red flags.

You should first talk (read note at the end) with your manager and explain the overview of the situation. Offer to create a report to show how the application:

• will be more expensive;


• will take a much longer development time;


• run slower;


• have more bugs;


• have more customer complaints;


• erode the morale of the team because of the mess.

Just show that this:

public boolean myMethod()

{

   if(somethingIsTrue==true)

   {

       return true;

   }

   else

   {

       return false;

   }

}

can be written as this:

public boolean myMethod()

{

   return somethingIsTrue;

}

or (if data hiding is not essential) even as:

somethingIsTrue

It should be easy to understand by anybody, regardless of education, that the original is uglier.

NOTE 1: if the manager decides in favor of the colleague, then there will not be much more that you can do.

NOTE 2: I underline "discuss", as opposed to "complain". The discussion should be started like along this:

"Boss, I am not sure if I noticed something right. I think (this), and guy X thinks (that). The simplest example is (this - have it with you, maybe a hard copy) with the negative impact (this). I need some support, in order to improve my skills, while improving the quality of our product at the same time. If the information is not enough, I can create a short list of examples, so we can discuss more to the point."

NOTE 3: Sometimes, the best solution is to go find another job. I have done that myself. But that is a defeat for yourself and for your career, if you do not try something else first - with decency, of course.

NOTE 4: "Installing" and then "enforcing" official coding rules is a long process in itself, and it usually leads to longer development times, and higher development costs (short time). The downsides are balanced (long term) by fewer customer complaints, less time "wasted" on debugging etc. Therefore, if there is no management support, coding rule are nothing but a beautiful dream.

That style of coding is not bad, it's just very verbose.

Depending on the language being used it may also be outside the normal for coding style as is commonly used across the industry.

In any case, unless there are specific style guidelines in use in the company or project that tell otherwise, there is nothing wrong with that code except that you have personal reasons for not liking how it's written, which has nothing whatsoever to do with whether the code is good or bad.

If there are no such guidelines in your company or project, it's overdue to start adopting some, and that should be done in good faith and by talking with everyone involved to get to a set of rules that everyone can live with (or at the very least everyone with any seniority and experience).

If there are such guidelines and the code violates them, THAT's the moment to point it out to him (politely of course). But you may not want to do that for existing code as changing code even to adhere to new coding style guidelines is liable to introduce bugs.

I'd like to extend on lucasgb's excellent comment : in the real world, most code is crap.

There are many reasons to that, the main one being the stakeholders panicking when the deadline approaches, transmitting their panick to the developpers, who then enter "quick and dirty mode", which they know they'll regret later - but still do it anyways. I've been guilty of this more than once.

There are plenty of other reasons why code can be bad : lack of guidelines, poor training, poor capacity to accept training.....

But your question goes even further. You're not as senior as this developper. There might be good reasons for him to use such a verbose style - or there might not be. The first thing to do would be to explore why he's doing that(I've got a few ideas, which I keep for myself, it's not a coding stack, there). You might think about it, or you might even innocently raise the topic, during a chat. "Hey, Mr Senior, I never saw this before, can you enlighten me about this design pattern?"(exact wording to adapt to the senior's personality).

Once you'll have a clearer view of the situation, you'll be able to decide wether it's actually a good practice - or not(my own opinion : if the function is well named, then it's worth the hassle. Though your milage may differ).

And only once you've decided that it's actually crap, it might be time to think about coding guidelines. And to discuss about coding guidelines with everyone. Without thinking you're always right. Nobody is.