## when adding a second option, align the name of the first option - why: - if not done, questions pop up all the time. - from the example below: Do Customers mean B2C or are they both B2B *and* B2C? - observed consequences: - less questions, less interruptions - the change might be needed on db level, file structure level, CI level as well - some changes might run too deep, so one needs to be pragmatic and sometimes accept the newly introduced inconsistency Example: ``` # before const Customers = ... const CustomersB2B = ... # after const CustomersB2C = ... const CustomersB2B = ... ``` ## when nesting is too deep, refactor to a more shallow structure - why: - as humans, there's only 5-7 concepts we can keep in our heads at the same time. - with each nesting eliminated, there's one less thing to keep in mind - observed consequences: - the new methods might become encapsulated reusable lego bricks, saving time in future - towards code that reads like a story Example: ``` # before if ... if ... switch ... if ... else if ... if ... if ... # after if ...: store_to_db(...) else ...: signal_to_the_enduser(...) def store_to_db(...): ... def signal_to_the_enduser(...): ... ``` ## aim for high locality of variable definition and usage - why: - things that change together should be placed together - inconsistency in location is a form of [[Decomplecting intertwined things|complexity]] - one less thing to have in mind, leading to faster code comprehension - observed consequences: - high locality seem to lead to emergence of reusable and/or well-named functions, that can be used as lego bricks. - towards code that reads like a story Example: ``` # before const user = ... ...10 lines without user ... store_to_db(user) # after ...10 lines without user ... const user = ... store_to_db(user) # maybe a new well encapsulated function with a good business meaning will emerge, for example ...10 lines without user ... register_user(name) ```