Skip to content
Hallway
0:00 / 0:00

#coupling#controlflow#conditionallogic

If considered harmful: How to eradicate 95% of all your bugs in one simple step - Jules May

DevWeek Events

3.2K subscribers • 2 videos on Hallway

YouTube
  • Recommended by 2 people: 1 on Lobsters and 1 in engineering communities.
  • A classic. People kept recommending it from 2020 to 2024.
  • Presented by Jules May
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

50K views11 years ago2 recommendations

Software designTools and practiceDesign patternsRefactoring and legacy codeSimplicity and complexity

Jules May argues that conditional if-statements introduce hidden coupling and bugs, and proposes alternative design patterns to eliminate them.

Breakout session from DevWeek 2015 devweek.com/ DevWeek is the UK’s leading conference for professional software developers, architects and analysts. With insights on the latest technologies, best practice and frameworks from industry-leading experts, plus hands-on workshop sessions, DevWeek is your chance to sharpen your skills - and ensure every member of your team is up to date. Please visit devweek.com/ for information on the latest event. ----------------------------------------­----------------------------------------­----- DevWeek is part of DevWeek Events, a series of software development conferences and workshops, including DevWeek's sister conference 'Software Architect' (software-architect.co.uk/), brought to you by Publicis UK. ----------------------------------------­----------------------------------------­-----

Why it's here

2 people recommend this

What people say. Recommended for its ideas on avoiding hidden coupling arising from duplicate conditional checks.

u/tobegain r/ProgrammingLanguages • Recommends

If considered harmful I was just rewatching the talk "If considered harmful" It has some good ideas about how to avoid the hidden coupling arising from if-statements that test the same condition. I realized that one key decision in the design of Tailspin is to allow only one switch/match statement per function, which matches up nicely with the recommendations in this talk. Does anyone else have any good examples of features (or restrictions) that are aimed at improving the human usage, rather than looking at the mathematics?
34View on Reddit

jhallon Lobsters • Recommends

If considered harmful: How to eradicate 95% of all your bugs in one simple step
11View on Lobsters

u/tobegain r/ProgrammingLanguages • Mentions

On “Can you demonstrate the value of OOP over procedural?”

In an if-statement you have to know at that point exactly what that object is, but if you just know that the object ca do the operation you need, you don't need to know exactly what it was. That means that with virtual functions you only have to change the code that calls your code when there is a new type, you don't have to change your code as well. One team figured out that 95% of their bugs were because of if-statements and the solution was always to add another if-statement. See where that goes? [video
12View on Reddit

u/tobegain r/ProgrammingLanguages • Mentions

On “Any love for early binding?”

The main purpose of late binding is to avoid an explicit if-statement on the type of the data object. One team calculated that 95% of all their bugs came from if-statements varying behaviour based on properties of the data, especially when those if-statements inevitably got repeated. Ironically, fixing a bug almost always meant introducing yet another if-statement to vary behaviour. see [video Common optimization techniques include branch prediction, and as I see it, early binding would then just be branch prediction. Note the value in being able to code your functions without having to know the concrete type, but after that your compiler may do whatever it can.
1View on Reddit