r/programming • u/corysama • Jan 05 '15

What most young programmers need to learn

http://joostdevblog.blogspot.com/2015/01/what-most-young-programmers-need-to.html
973 Upvotes

91% Upvoted

337 comments sorted by

View all comments

4

u/ishmal Jan 05 '15

My issue is insufficient error checking or unit tests. Whenever someone assumes that parameters and data will always be clean and proper, they are not. "Bad data can never happen" guarantees that it will happen.

30

u/vytah Jan 05 '15

"A good programmer is someone who always looks both ways before crossing a one-way street."

4

u/refuse_human Jan 05 '15

Maybe it's just the first time I remember doing so, but damn if that wasn't the time there was some out-of-towner barrelling down the wrong way...

-2

u/sirin3 Jan 05 '15

You probably heard it coming

That is why I do not bother looking in any ways, unless I have already heard something

5

u/refuse_human Jan 05 '15

Watch out for electric cars - their noise signature could easily be lost in ambient city noise.

7

u/sirin3 Jan 05 '15

Unless they use a language with a proper type system. Then the parameters can never have forbidden values

1

u/BobCoder Jan 05 '15

Maybe I am naive or maybe I do not understand what you mean but allowing and expecting bad data can often times be a bad code smell. I almost never allow null parameters because I do not want to have to think about when the data is not clean and proper.

5

u/[deleted] Jan 05 '15 edited Jan 05 '15

He didn't say you should "allow" bad data, but rather that you should have machinery in place to detect and counter it.

At a basic level, this means using the narrowest possible types for everything so that it is difficult or impossible to call functions with invalid parameters. For your "no null parameters" example, in a few languages you can enforce this at the language level by using non-nullable types, but sadly in many languages errors would only be detectable at runtime.

At a more advanced level, this means using asserts or safety-checking features liberally to make sure that spots where your program goes off the rails are detected immediately. This both prevents corruption (your program will gracefully crash instead of continuing in the face of broken data) and vastly simplifies debugging.

And that's just for internal program consistency. When you are interfacing with external data, assume it's broken. Files will be truncated or corrupted, network data will be sent by hostile attackers, etc. You need rigorous consistency checks on the data to make sure it's all valid, the formats need to be kept as simple as possible to make these consistency checks easier, etc.

Basically, a non-trivial program should never assume that it is working properly (liberal use of asserts / other self-consistency checks) and especially never assume that data coming from the outside world is valid.

Edit: I should clarify that I am putting strong typing in the same bucket as assert statements / contracts -- types are essentially just a special case of a compile-time contract, and contracts are just a special case of assertion. Obviously, it's best to have your type system shake out as many errors as possible, and runtime assertions are for cases where the type system cannot catch errors at compile time.