>>>>>I also think all who are replying with words like "that's bad programming" do not fully understand the psychological aspects that are involved in programming. The counterpart of Thundering Train Programming may well be a defensive programming style that is the result of fear, fear of being blamed for every flaw in the appplication. The programmer will therefore spend precious time on programming many checks and double-checks that will always (yes, litterally always) gonna evaluate to the same result.
>>>>>
>>>>>When applied to the right parts of an application Thundering Train Programming is legitimate and probably even superior, as I see it. What parts? While being in the station, the train personnel must be cautious, because the users can show varying behavior. When leaving the station the train driver can increase speed and needs not check whether or not there are actually rails. No, the rails will be supposed to be there, simple. Upon entering the next station, cautious behavior is required again. Regard at least the user input windows as stations.
>>>>
>>>>Then why do trains have horns, brakes or even conductors? Should be a simple piece of code to drive the train. If the train runs out of control, it is not because there are no precautions. There are always precautions.
>>>
>>>Sure, there are all kinds of precautions. But the driver is not driving slowly just in order to see whether or not there really are rails right in front of him. Those rails are assumed to be there. Driving slowly would likely be an indication of unjustified fear.
>>
>>The typical train is not designed to run at 3,000 MPH because the tracks have too high a margin of error. The train is slower than it could be. Bullet trains run faster and have more accurate tracks as a result. Maglev trains are even faster but no matter the train, they all cannot exceed speeds where they can travel safely. They definitely go slower than they could.
>>
>>Building in checks in the code is like building breaks into the train, it is not like driving slowly. The weight of the brakes, the engine power used for the brake hydraulics, the brake fluid and lines all actually reduce a car's ability to accelerate and its top speed. A car is definitely going slower as a result of necessary safety requirements.
>
>I think I have made clear constantly in this thread that checks need to be programmed at every place that should have one or several according to the functional specs. The checks you are describing here are for sure prescribed by functional specs. The thing that I'm challenging is the habit of some/most of us to even code a check at places that need no check according to the (well thought out and agreed upon) functional specs. If the spec says that there will be a rail, then the driver need not check whether there actually is a rail. With this thread I hoped to raise awareness that we are at times programming too defensively, probably out of fear being blamed for each and every bug. It was NOT a pledge for careless programming. All who have explained it that way, have misunderstood the concept and need to reread the whole thread. I think the next step for us, professionals, is that we develop a sense for when checks are really required and when they are actually useless. I also think
>that a comment line in the code should tell why a check is not done there. So, not only document what is done, but also at times what is not done, for the sake of the next developer who has not yet developed that sense.

But why bother to document the lack of the check? If it's in the specs as you say, there's no need. Humbug! The specs are made by humans, the code is made by humans. The checks should be there to protect us from ourselves. To err is human to forgive devine and your boss/customer is no god. They will sue you or your company - possibly forcing you out of a job - at the drop of a hat. The functional specifications do not state that society has become particularly fond of lawsuits. The specifications never mentioned Y2K issues and look at what that caused.

I do like that you want to call it thundering train because it is like an out of control train. Professional should be following good, safe practices. Thundering train programming is possibly OK to do in some cases, but it it increases the margin for human error multiplied by the speed of the computer multiplied by the number of inter-related subsystems.


>
>>There is no requirement for safety in extremely simple - I can't tolerate calling it an educational - example
>>
>>for i = 1 to 10
>> ? i
>>endfor
>>
>>but the instant it becomes
>>
>>for i = 1 to 10
>> ? sqrt(i)
>>endfor
>>
>>There is a required element of safety demonstrated in all programming languages, spreadsheets etc.
>>
>>When you assume you make an a__ of U and me. It's part of why I use mdot. I will not assume you will follow my or any known naming conventions. In fact considering how many conventions seem to exist, I am convinced it's the right and safe thing to do.
>
>I assume you are refering here to using m.i, even if the programmer is sure tat there will never gonna be a table selected at that moment that has a field named i? I agree with you on this one. The reason being that the second instruction is simpler to keep in memory than the third one:
>
>1) Always use mdot if using a variable.
>2) Always use mdot if using a variable in an evaluation.
>3) Always use mdot if using a variable in an evaluation, unless the specs promise that it's impossible that a same named field is present in the current workarea at the same time.
>
>But I do not support the idea that the mdot should also be used when assigning a value to the variable. That definition is too simple for me (and many others here). We have discussed that several times here in the past, as you know.

I understand. However, since you're basically arguing that there's no harm in thundering train programming under certain circumstances, would you be so kind as to recognize that there is no harm - under any circumstances - in my using mdot everywhere I can. There may also be a benefit in that I don't have to try to remember when to do it and when not to. It's an easier habit to just do it everywhere.

I'm trying to find an example of Thundering Train programming in other industries. I'm having a hard time. A CPU to the best of my knowledge does not have an external fuse because there is a fuse on the motherboard in case of power spikes. The specifications for the CPU indicate the power environment. However are there not resistors inside the CPU? Don't they condition the power for different parts of the chip?