-3

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.

closed as off-topic by gnat, Sourav Ghosh, Fattie, Mister Positive Apr 17 at 12:18

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    There's the correct thing, and then there's what is accepted in a team / organization. It's a tough choice to make. – Sourav Ghosh Apr 17 at 7:49
  • 1
    Don't you have a code review in place? That's the first thing to do. – Adriano Repetti Apr 17 at 7:55
  • 9
    This can easily be refactored and has no impact specially if it's compiled. All code is crap, welcome to the real world. – lucasgcb Apr 17 at 7:56
  • 1
    @ewanc or in the past there was more being done that was since removed. Things like logging, writing audit trails. – jwenting Apr 17 at 10:33
  • 4
    This isn't bad code, this is a debugger trick. Writing code that way enables you to selectively put breakpoints on either False or True returns, which can help - a lot - to find hard-to-reproduce bugs. – T. Sar Apr 17 at 12:13
-9

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.

  • Comments are not for extended discussion; this conversation has been moved to chat. – Mister Positive Apr 17 at 12:18
  • You've been 15 years in the industry? Then certainly you know that code like this one on the original question allows for selective breakpoints on either branch of code to help to find hard-to-track bugs, right? You also probably knows that this type of coding is very common when preparing the system for future logging or extra features, right? More seriously, now - as someone who has had to deal with very basic compilers and debuggers from time past, I used this type of trick all the time to make sure my code would break only when I needed. This isn't bad coding. It is just a debugger trick. – T. Sar May 2 at 11:26
12

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.

  • It's just not my personal opinion, although I happen to agree with it. This verbosity is completely unnecessary, it adds unnecessary complication without any real value in return. How many level of verbosity would it take to call it bad? could I write "if value=true then set a= true and then if a= true then set b= true.... and so on. – akbar hussain Apr 17 at 10:03
  • 4
    @akbarhussain I agree I'd prefer a less verbose style as well, but many people disagree. It took me several months of effort in my last company to get the coding styles changed to allow for the equivalent of the shorter "return ifSomethingIsTrue", and in my current job to allow ternary operators (they'd been disallowed because some people found them confusing). Remains that without an agreed upon standard for the project or company there's nothing wrong with the code except the personal preferences of you and some others. – jwenting Apr 17 at 10:32
4

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.

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