Do we teach the danger of hard-coding?

[bclaremar]

No description provided.

[richelbilderbeek]

I don't, as I feel making code testable reduces this bad practice enough. Should I spend more time on this?

[richelbilderbeek]

I think the bigger question is (even) more interesting: how do we as a group decide what an individual teaches? What if that individual is wrong? I'll think about this :-)

[bclaremar]

Examples that we cover or could cover

• make analysis work for different data (or at least different files with same format)
• avoid control of program through comment/uncommenting code
  • instead use if/else and possibly arguments when running program

[richelbilderbeek]

I think this is useful and I will add it where I can if I consider this useful enough to teach within the time I have.

Thanks!

[bclaremar]

and of course I forgot:

"using variables that can easily be defined instead of numbers at several places that may change as you decide to do updates/bug fixes."

Would you agree on just gathering a list of such "soft coding tips". May that be sufficient? Would fit where variables are covered?

Or do I have a bad understanding of what hardcoding is?
Well, Wikipedia gives a bit more narrow definition of softcoding. They say that softcoding requires external files or arguments.

[bclaremar]

https://en.wikipedia.org/wiki/Hard_coding
https://en.wikipedia.org/wiki/Hard_coding#Softcoding

[richelbilderbeek]

Yes, I think this is useful and I will add it where I can if I consider this useful enough to teach within the time I have.

I understand hard-coding. I will pick teaching good practices over teaching bad practices to be avoided (all else being equal). Still, hardcoding does deserve some attention. The question is if it will reach the priority list, not if it is on it 👍

[LinusSch]

Thoughts upon reading this (before reading the course materials, but having learned these things through courses, various publicly available resources, and experience):

Generally, do teach the good practice to follow - only in the most important cases, briefly mention the bad habit on the other side of the same coin.

For hard-coding there is (unless I've missed something) essentially two basic cases, one intermediate case and one advanced case:

1. Magic numbers or strings - i.e. failing to use a variable to define a constant
2. Control by commenting - i.e. failing to use a variable to define the program path
3. User input not cached - i.e. failing to put user input into a variable, having the return value directly control things
4. Using a variable but not exposing it to the user - i.e. failing to use command-line arguments and switches, or a config file, or user interaction

For the two basic cases it makes sense to very quickly explain the problem: you'll kick your immediate past self for making coding hard. The intermediate, sneaky, case 3 probably needs an example even though the problem is exactly the same - just less obvious and perhaps less immediate. (There is also the related structural problem that user input gets scattered all across the code, maybe even scattered in time along the program run.)

But for the last case I suggest to avoid it until specifically asked about it - people will see this easy way out, like it, and use it - no matter how you explain the problems.

The problems simply do not apply to a coder without a userbase (or a long compilation). In a great many cases, many of which are found in research, it can easily be argued that it just isn't a problem! Of course it is common, especially for choosing data files to be worked upon by a script. I have seen fairly advanced code with all the configuration variables neatly organized and explained at the top of the code, even in a separate "config" source file at some point.

It may well be a lesser evil, it is at least relatively easy to get out of. The first reoccurring problem with top-of-code configuration is that one fails to consider it user input and therefore fails to sanity check the values of those variables - but at that point we've already strayed from this topic to somewhere a bit further into the course.

[richelbilderbeek]

Thanks @LinusSch, I enjoy your thoughtful post! For me to add it to my material, I do need to (1) be convinced I should teach this, and (2) have references to the literature.

It may be overkill to already give references to the literature in an issue, yet I will ask for them by the ones that convinced me :-)

But hey, let's ask: @LinusSch: which book did you quote, or did you remember this from a now-unknown source?

[LinusSch]

@richelbilderbeek: As mentioned in parenthesis in my opening sentence: various now-unknown sources. Some of that post is probably original thoughts, e.g. I constructed that list of four cases after reading this discussion and some of the linked Wikipedia page by simply writing the cases down and thinking about them for a while (I started with two cases). It may or may not be the best summary of various cases of hard-coding. It may or may not exist in very similar form elsewhere. These two maybes are only slightly if at all linked.