There is a long boring ISO/IEC technical report 24772:2013 with a long boring name: “Information technology — Programming languages — Guidance to avoiding vulnerabilities in programming languages through language selection and use”. It has two distinct purposes: first is thinning engineer population by boring them to death, and second — saving lives. It is primarily applied in safety critical areas, such as nuclear power plant automation, aviation, automotive, medical equipment and so on. Everywhere where the cost of silly error is more than a furious feedback from your customer. And among all the boring stuff it contains, there is one particularly stupid rule: Use a final `else` statement or a comment stating why the final `else` isn’t necessary in all `if` and `else if` statements. Well, it obviously stupid: it tells you to do extra work for no benefit at all. Just writing something like “ ” here and there wouldn’t be much help, would it? is // this 'if' case doesn’t need 'else' It turns out, it would. I respect this rule since 2013, and there have been numerous occasions when simply thinking about the final helped me write better algorithm. It’s really easy to overlook proper handling for the worst case scenario when you are too concentrated on what to do when statement complies. Simply treating “empty” as suspicious prevents logical errors at the earliest possible stage. if if else We all know, these are the worst errors; and this is the best stage. For instance, I’ve been working on complicated image format reader lately. If put simply, it goes like this: read integer gray values from the file;convert integers read from the file to floating point numbers;if required, make sign compensation;if required, make rescale;if required, invert gray value;...convert floating points to integers again. Obviously, none of these need an . But you know what? All of them together — do. If none of these conditions are met, we don’t have to do floating point conversion on our data as well. I did a small research and found out that these cases are not at all rare. In fact, some of our heaviest examples already come ready in a file, and they do not require any post-processing indeed. I only had to add a couple of lines to account that. if else read integer gray values from the file;if any processing required,convert integers read from the file to floating point numbers;if required, make sign compensation;if required, make rescale;if required, invert gray value;...convert floating points to integers again.else// output values are the same as in the file This smallest change alone makes it all work times faster for a significant amount of use-cases. And it could have been easily overlooked because the code looks fine as it is. It requires a stupid rule to make it look wrong. I’m not telling that stupid rules such as this should be followed neurotically. Look, I didn’t follow “else” rule for the most of the “if”s here myself. But given that it costs so little effort to follow and often results in rather significant improvements, ignoring the stupid rules such as this would not be the smart thing to do. P. S. By the way, here is the nice source of publicly available ISO/IEC standards and reports packed with stupid rules like this: . http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
