How 'child proof' should i write code as a solo programmer? [duplicate]

Question

This question already has answers here:

How necessary is it to follow defensive programming practices for code that will never be made publicly available? (6 answers)

Closed 6 years ago.

In our company there once were multiple programmers, now i am the last man standing. I have inherited all the code and i maintain, rewrite, extend (,fix) it.

I always run into this behaviour that i try to make stuff fool proof so that a dummie co-worker couldnt mess up the code. But there are limits to what i can do. I cannot prevent that someone holds a reference to an object. Even java/android system classes give you an object that you are not supposed to hold on to but just use it locally and thats it.

In our company a lot went wrong and i am kind of a burned child, i see possibilities how someone could do the wrong thing and the code keeps crashing and I am asked "why do you write stuff like that"...

Right now i am the only programmer but in the future maybe we have more (again), but right now i kinda restrain myself by spending too much time on trying to figure out how i could write my stuff so that the least amount of mistakes can be made with it. Even tho I would be the one who had to make the mistake.

Like everyone i do make mistakes ofc. So i null-check etc and write limits into the java-docs to remind myself what values i may pass etc. those simple checks are not what im talking about. I am talking about that often i could write a method in a simple and good way but some voice in my head says "oh no, what if SOMEONE would pass a wrong parameter or did this and that with it" and suddenly i find myself encapsulating logic and making stuff more complicated only to add some sort of protection against... dummie programmers with me being the only one possible.

I am NOT working on any open API or shared stuff. There will (most likely) never be any code audits etc. I am the only one using the code and it will stay like that for a long time.

So how do i stop myself from doing this fool-proof coding that costs me too much time and brainpower.

EDIT: i read the other question + answers. I understand the whole 'defensive programming' but i wonder when am i taking it too far ? And thats more my problem.

Answer 1

As someone who started in Basic and C; I have a policy:

If it can explode, make sure it explodes.

Paranoia with error checking and defensive styles often create slower and more difficult to debug code. (And can introduce its own bugs) The reality is that code must be documented and that you should expect a reasonable developer to use it. If you are doing null checks all over the place then there is something wrong with the design in general.

The more you try to hide things the more you often hurt yourself or your team. It comes back to bite you in the butt.

Answer 2

The best way to make code child-proof is to make it decoupled into modules, then each module can have its API documented, and can be designed to do 1 thing well.

This will not stop a child taking your network module and putting it into DVD slot, but it will allow you to tell them off afterwards for not using it as it was intended - as proven by the documentation.

This does mean you have to spend more time designing your classes and modules and the interface boundaries, but its time well spent.

Answer 3

Okay, so what I understand you are trying to get at (maybe understand), is that you need to make sure that no-one messes up your code? (because if they messed up the code things would break). Maybe the solution to your over-worrying is not making your code child proof, but instead, increasing redundancy, you should consider using subversion. Subersion basically allows you to save a project to a repository (repo), then when you want to make changes to the code, you 'branch' the project, meaning that you (or any other programmer) can make changes to the code in this branch without it affecting the 'trunk' (main copy) so if the code does get messed up, it is only in the branch and not actually in the real version, but if significant improvements are made to the code then you can merge your branch with your trunk meaning that the changes take place in the real working copy! So as long as these 'dummie' programmers are only working on the branch, then nothing gets messed up. Another cool function is if it does get messed up in the trunk, you can just go back in time to a time when those changes weren't made. Subversion really is a life-saver, consider beanstalk as your repo-base and TortoiseSVN as your subversion software.

Answer 4

I like the answer of @misterbiscuit, although I'm a Java guy and have very little experience with C (seems some concepts are exchangeable beyond the programming language).

I'd like to amend:

• If you write software someone's (my) life could depend on, I'd encourage you to double- and triple-check every fckn value. Otherwise, read on.
• Conventions - if null is a valid input-paramter, you need to check it. If, by convention, null is not allowed (but for some special cases), you can assume you won't get it. There are good books available every developer should have read ("Clean Code", "Effective Java")
• Unit-Tests - when changing legacy code, I tend to write unit-tests for the current behaviour. This leads to many tests that seems to be wrong, in fact it is just the behaviour of the production code that made me to write the test that way (to make it green). You could do the same trick, but upfront - write tests that document the current behavior.
• Documentation - it's necessary to write down architecture and concepts in a meaningful extent. Nobody reads a 300 pages document before starting coding (except it is called "Java for Beginners"). I like the concepts of arc42, because you can document architecture in 3 pages, if you like. and then add some common rules and you are done. (However, it depends on many more factors of how documentation will be)