Timeline for Is it logical to not use inheritance because the function is critical?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 22, 2023 at 0:59 | comment | added | candied_orange | @WernerCD I can see both happening but the fundamental problem is it’s a meme. It replicates because someone looks at this useless else that does nothing and asks why it exists. When told it’s to protect against idiots there is no handy test to disprove it because no one wants to admit they’re an idiot. So they cave in, accept it, and replicate it. | |
| Dec 21, 2023 at 21:26 | comment | added | WernerCD | Clarification: Protect the idiot... Are you talking basically cargo cult (rules without a purpose)? en.wikipedia.org/wiki/Cargo_cult_programming or is this a monkey problem (rules where no one knows why they exist anymore)? proserveit.com/blog/five-monkeys-experiment-lessons seems like a variation of the two rules | |
| Dec 21, 2023 at 12:41 | comment | added | candied_orange | @Graham I've no problem with justifying exceptions. I've a problem with not justifying forced compliance. The people who wrote the linter haven't looked at the code. The responsibility, either way, should rest with the people who have. | |
| Dec 21, 2023 at 8:37 | comment | added | Graham | @candied_orange The principle though isn't following the linter, it's following the rules and knowing why. For another, we had issues with making sure reads and writes to variables were atomic on a multi-rate system, so we rolled our own static checker for that. But a few years later, knowing about atomic reads/writes being an issue, as a contractor I fixed a bug in my first afternoon on the job literally while the rest of the team were discussing how to spend the next fortnight analysing what was happening. They were smart people, they just hadn't been exposed to the same rules as I had. | |
| Dec 21, 2023 at 8:30 | comment | added | Graham | @candied_orange Sure, the linter is a guide, not the whole thing. I'm not arguing for being forced to blindly follow it - but I'm definitely arguing for being forced to justify exceptions. Humans are highly fallible, and that's the big lesson in safety-related work. Ideally though it's not a separate step - it's something you do continuously through your code. BTW, one genuine bug was a potentially uninitialised variable, where it would have been hard but definitely possible to hit the uninitialised case. | |
| Dec 21, 2023 at 1:46 | comment | added | candied_orange | @Graham "found us several genuine bugs" If you're confident in claiming they were genuine then I'm confident you can explain why. I'm arguing against blindly refactoring code into compliance when you have no idea why you had to change it other than cause the linter said so. I've been in meetings where we were told we had to do exactly that. Clueless compliance does not grant safety. This field is less than 100 years old and the wisdom is changing fast. If you're not in the room looking at the real code you can make suggestions but you don't get a vote. | |
| Dec 21, 2023 at 0:44 | comment | added | Graham | ... And I'll also be the first to say that those rules regularly don't make sense for writing good code. Limiting function length, in particular, regularly fails in the face of switch-case statements. But if you know why you're breaking that rule, you've thought about the situation. You've probably added a linter exception for the rule above that function. And you've probably added a comment next to that linter exception so that future maintainers know the score. That's what a defensive engineering process looks like. | |
| Dec 21, 2023 at 0:39 | comment | added | Graham | I learnt my core software engineering skills in automotive software. We bought PC-Lint for our first SFPD project, enforcing MISRA standards, and we checked every report to see what it got us. This was code that had been reviewed, unit-tested and system-tested already, by the way. And it still found us several genuine bugs, which were all avoidable if we'd "protected the idiots". Because the basic premise of safety-related engineering is assume you're going to get it wrong and then look at how the process catches that failure. | |
| Dec 20, 2023 at 18:04 | comment | added | Stef | In my opinion these "silly rules" are really great in the first year of a developer school, and they're pretty bad outside school. At school they help new developers get good habits. Take an arbitrary rule like "the code of a function must never be greater than 15 lines". That's a very efficient rule in a school to teach novice developers to decompose their code into logical units. But it really sucks if you have to follow this rule at your dayjob (and inevitably end up hitting your code with a hammer occasionally to make it fit into the limit). | |
| Dec 20, 2023 at 17:08 | comment | added | Stephan Samuel | There are better tools than unreasonable rules and linters for finding errors in code, like unit tests. A single, DRY implementation that is tested is generally considered to be better than repeated re-definition of the same code. If the problem set of a particular function handles lots of cases, perhaps it is better to split it and use composition. parent::solveWorldProblems() is better as solveInChild() { parent::solveWorldHunger; parent::solveWorldPeace(); }? | |
| Dec 20, 2023 at 16:36 | history | edited | candied_orange | CC BY-SA 4.0 | added 5 characters in body |
| Dec 20, 2023 at 16:31 | comment | added | candied_orange | @amon oh I’m an idiot as well. I’ve no objection to reminders. But, much like fire, tools are a good servant, but a poor master. I like them except when used as a substitute for judgement. If you want to argue with me at least be in the room. Not hiding in some rule. Now that said, I think “strict” is a very nice language feature. | |
| Dec 20, 2023 at 16:23 | history | edited | candied_orange | CC BY-SA 4.0 | deleted 14 characters in body |
| Dec 20, 2023 at 14:35 | comment | added | amon | Yes but I am an idiot, I want tools to help me protect the code from myself. As long as warnings are reasonably sparse, an "are you sure?" check can be helpful. In OP's case, this might be as simple as putting the default implementation into an abstract base class method, so that authors of new subclasses have to think for a second whether they really should insert that super() call. I recently suffered a two week long debugging session because we forgot to provide an optional parameter, requiring an explicit choice would likely have prevented it. | |
| Dec 20, 2023 at 0:28 | history | answered | candied_orange | CC BY-SA 4.0 |