What programming best practice do you disagree with?

I've been recently asked this question in an interview and this was my answer:

Pure unit tests and shallow rendering idea

For ReactJS in particular, there are many testing libraries that allow you to do shallow rendering (enzyme for example), that means that if you have a composed component, the test won’t actually render that inner component so you can’t make assertions on that. If you want to cover those internal components you need to write specific tests for each part.

For example:

<div>
   <Form>
      <Username />
      <Email />
   </Form>
</div>

With this structure, if you want to write a test for this component, the first div will be rendered but the custom Form component won’t, neither the Username and Email components, they will be mocked. You will have to test them individually, which follows the pure unit testing idea, but you can’t ensure that the components work ok together.
If you follow this pattern, you will soon end up with a set of pure unit tests that are really confusing and hard to follow.

Tests should resemble the way the software is used. Even though is not pure unit tests (technically you can call it integration test), at the end of the day the only thing that matters is that you can ship your app with confidence.

Resources:

• @kentcdodds
• Testing React Applications, v2

Image by Gerd Altmannfrom Pixabay

Comments

[Eileen McCall]

I have a lot of opinions about JS style that might a bit uncommon or idiosyncratic

var > let > const

{
  let x = 1; // let for block level vars
}
const pi = 3.14; // const for string/num constants
var y = 3; // var for everything else

Double quotes for strings, always

var yes = "good";
var no = 'bad';

Space before function parens in declaration, no space before invocation

function foo () { }
foo();

ONLY use arrow function when you require lexical this, and NEVER (well, almost never) use anonymous functions. Also, no arrow functions without curlies (I make exception for simple pluck operations because I'm lazy).

[1,2,3].map(function timesTwo (num) { return num * 2; });

var timesMultiplier = (num) => { return num * this.multiplier; };
[1,2,3].map(timesMultiplier);

userAPI.getUser().then(usr => usr.id); // this is fine I guess

[James Eastham]

Getting hung up on high code coverage from testing.

Code coverage is a great metric, but not the be all and end all. 100% coverage but no test of how the software is actually used is largely irrelevant.

[Nabil Tharwat]

Agreed. I wanted to add a different perspective to the discussion since most of the time the points that are focused on are abstraction, readability/testability, and length.

There are times when it's necessary to make functions long, and others to break them up into smaller units, as long as doing so has a measurable impact, makes the logic involved clear, and goes according to project goals.

[Nabil Tharwat]

It's not only about abstractions nor length. If a function becomes too long the engine won't be able to optimise it if the size of the bytecode generated after compiling the function exceeds 64 KiB in the case of Java on JVM, and 60 KiB in the case of JavaScript on V8, even if the function is considered "hot", invoked very often, that is. So, it's more about measuring the trade-offs of using longer functions vs breaking them up into smaller ones.

Edit: I just realised this was posted over 4 months ago.

[Yawar Amin]

I kinda was in that camp ... but have changed my mind over time. Extracting functions out is not about length (although that doesn't hurt), it's really about levels of abstraction. Each function should be dealing with one level of abstraction. Anything at a lower level should be in a separate function. This leads to a top-down, layered architecture where layers are modular and swappable. More about this technique in this great talk about writing quality code: youtu.be/CQyt9Vlkbis

[Jason C. McDonald]

I don't know that I really label any practice as unqualifiedly "terrible," but I don't agree with anything being followed religiously. I tend to disagree with...

• "No Comments" rule of Clean Coding, although I still advocate all the rules of self-commenting code.

• TDD in and of itself. I strongly recommend testing, however!

• Agile, unless one takes the time to determine how the practices fit into the team's workflow. (True of any project management methodology, though.)

• Auto-generated documentation. I still recommend documentation comments, including Javadoc/Doxygen compliant ones, but I believe documentation should be written by hand.

• Knee-jerk compliance with Clean Coding, DRY, SOLID, or literally any other coding pratice. These are great in and of themselves, but you have to supply your own common sense.

That said, all of the above have their place! My issue is seldom with the practice; instead, my concern is with a blind, unilateral compliance on those practices.

[Han Mai]

couldn't believe more on auto-generated DOC. It's suck sometimes. Make a short code looks never ending. Comment is everywhere.

[Olivier “Ölbaum” Scherler]

Yoda conditions. A lot of PHP projects write if(42 == $value) instead of if($value == 42), to avoid the mistake of forgetting an equal sign and getting an if($value = 42) statement with an assignment in it, that thus will alway be true.

Except that in PHP, you need to write if(42 === $value), otherwise you are vulnerable to shady automatic type conversions. And those projects also write if(42 !== $value), if(42 < $value), etc, for symmetry, even though there are no mistakes to avoid in these cases. The result is code that is annoying to read, and you have to train yourself to not forget to reverse the operands, when you already trained yourself to not forget the third equal sign. It simply has no benefit.

[Talha Mansoor]

A lot of C code, that I have come across, also has this issue, and for the same reason, "to avoid the mistake of forgetting an equal sign".

[Chris James]

Lol

[Jonathan Kuhl]

Yeah, they changed it recently (don't remember how recent though, ES6?) and now some devs think it's a great thing to do. I dunno, I hate it lol.

[Klaus Donnert]

I believe it threw an error in IE only.

[Brad Dougherty]

That's the reason for using tabs though. Everyone can set their display preference to their liking. You can use a width of 2 if you prefer, while I can use the 4 that I prefer (or whatever the numbers are, it doesn't matter).