5 ms·

I wish there was another Gang of Four with a book on codebase design decisions, some of which you had outlined. I need the alternatives laid out clearly and, mo

I wish there was another Gang of Four with a book on codebase design decisions, some of which you had outlined. I need the alternatives laid out clearly and, more importantly, given catchy names that I can refer to when real, or self-appointed code reviewers show up. How do I explain what my prefered "level of abstraction" is and why it is superior to all the others? How can I be convincing with a fuzzy and subjective term "visual noise"? Etc.

TeMPOraL 3y ago
> How do I explain what my prefered "level of abstraction" is and why it is superior to all the others? That's my point: you shouldn't, because there isn't. Once you hit the Pareto front, there's no superior choice. There are just choices, each of which is better in different situations, and once taken, very expensive to back out of. The problem is being forced to make the choice in advance. > How can I be convincing with a fuzzy and subjective term "visual noise"? That's another part of the problem. Different choices may be better for different people. There's no one-size-fits-all here. Which is why, again, it's dumb that we have to make this choice once and for everyone (part of what I mean by "working on single-source-of-truth code"). The way I see it, to stop running in circles on the Pareto front, to move past to more powerful ways of dealing with complexity, we need to make things like "lots of small functions vs. few fat ones" or "exceptions vs. expected" to be subjective, personal, local preferences, not meaningfully different than your editor's color scheme, or syntax highlighting scheme; inlining needs to be as easy as code folding, etc.
- PeterisP 3y ago
  Your arguments still seem to lead me to the entirely opposite conclusion - that different choices would be better for different organizations and different projects, and it would make sense to have things like "lots of small functions vs. few fat ones" or "exceptions vs. expected" to be well-known tradeoffs where the choices would be made according in an objective manner according to the type of the project, and override personal preference because for this thing we'll explicitly optimize for this type of reader because we believe that this codebase has XYZ properties and will be maintained at ABC level by DEF kind of people.
  - TeMPOraL 3y ago
    My argument is that those are fundamentally not project-level tradeoffs, those are "whatever your current ticket is about"-level tradeoffs. Your task may be such that you'll want opposite choices to have been made within 5 minute span - e.g. "lots of small functions" to get the gist of what the module is doing, followed by inlining everything into a single fat function along a vertical, after you found what piece of logic you want to debug. Both might also benefit from temporarily pretending error handling is done by unchecked exceptions, to remove visual clutter. I.e. you're talking strategy and architecture, I'm talking not even tactics, but individual minute-to-minute execution.
    - PeterisP 3y ago
      IMHO at the ticket-to-ticket level you're not really making these tradeoffs but rather experiencing the consequences of them - it doesn't matter if for minute-to-minute execution right now lots of small functions would be better or worse, you either have them or not; and whatever tradeoffs you make for the code you write during this one ticket, it should take into account the potential future readers.
      - TeMPOraL 3y ago
        > it doesn't matter if for minute-to-minute execution right now lots of small functions would be better or worse, you either have them or not; and whatever tradeoffs you make for the code you write during this one ticket, it should take into account the potential future readers. This is precisely the problem. The way it should look like is, these trade-offs should be purely local, minute-to-minute editor preferences. Inlining some helpers or removing error types from the code you see, should be no harder than folding a code block or pinning a peeked function definition. Nor should those "changes" have any effect visible to anyone else. You should not take into account any "future readers", because there won't be any - but rather, you should pick a representation you need right this second, and switch to a different one the moment you need that, etc.
        PeterisP 3y ago
- UweSchmidt 3y ago
  Until future tech allows for reformatting code to a developer's preference (which might not arrive any time soon or might introduce subtle new bugs, who knows) we could use some framework to make transparent decisions around that Pareto front, no? (Of course there is a best way to do it that will optimize the codebase for a function of productivity, reliability and pleasure. The likelihood and the cost of changes are part of that function. Finding and advocating for it is the task of the most experienced, wisest team member. Less experienced team members may (or may not) understand the wisdom of the better decision in time. But this is just my struggle with postmodernism and relativism and besides the point)

TeMPOraL 3y ago

> How do I explain what my prefered "level of abstraction" is and why it is superior to all the others? That's my point: you shouldn't, because there isn't. Once you hit the Pareto front, there's no superior choice. There are just choices, each of which is better in different situations, and once taken, very expensive to back out of. The problem is being forced to make the choice in advance. > How can I be convincing with a fuzzy and subjective term "visual noise"? That's another part of the problem. Different choices may be better for different people. There's no one-size-fits-all here. Which is why, again, it's dumb that we have to make this choice once and for everyone (part of what I mean by "working on single-source-of-truth code"). The way I see it, to stop running in circles on the Pareto front, to move past to more powerful ways of dealing with complexity, we need to make things like "lots of small functions vs. few fat ones" or "exceptions vs. expected" to be subjective, personal, local preferences, not meaningfully different than your editor's color scheme, or syntax highlighting scheme; inlining needs to be as easy as code folding, etc.

PeterisP 3y ago
Your arguments still seem to lead me to the entirely opposite conclusion - that different choices would be better for different organizations and different projects, and it would make sense to have things like "lots of small functions vs. few fat ones" or "exceptions vs. expected" to be well-known tradeoffs where the choices would be made according in an objective manner according to the type of the project, and override personal preference because for this thing we'll explicitly optimize for this type of reader because we believe that this codebase has XYZ properties and will be maintained at ABC level by DEF kind of people.
- TeMPOraL 3y ago
  My argument is that those are fundamentally not project-level tradeoffs, those are "whatever your current ticket is about"-level tradeoffs. Your task may be such that you'll want opposite choices to have been made within 5 minute span - e.g. "lots of small functions" to get the gist of what the module is doing, followed by inlining everything into a single fat function along a vertical, after you found what piece of logic you want to debug. Both might also benefit from temporarily pretending error handling is done by unchecked exceptions, to remove visual clutter. I.e. you're talking strategy and architecture, I'm talking not even tactics, but individual minute-to-minute execution.
  - PeterisP 3y ago
    IMHO at the ticket-to-ticket level you're not really making these tradeoffs but rather experiencing the consequences of them - it doesn't matter if for minute-to-minute execution right now lots of small functions would be better or worse, you either have them or not; and whatever tradeoffs you make for the code you write during this one ticket, it should take into account the potential future readers.
    - TeMPOraL 3y ago
      > it doesn't matter if for minute-to-minute execution right now lots of small functions would be better or worse, you either have them or not; and whatever tradeoffs you make for the code you write during this one ticket, it should take into account the potential future readers. This is precisely the problem. The way it should look like is, these trade-offs should be purely local, minute-to-minute editor preferences. Inlining some helpers or removing error types from the code you see, should be no harder than folding a code block or pinning a peeked function definition. Nor should those "changes" have any effect visible to anyone else. You should not take into account any "future readers", because there won't be any - but rather, you should pick a representation you need right this second, and switch to a different one the moment you need that, etc.
      - PeterisP 3y ago
UweSchmidt 3y ago
Until future tech allows for reformatting code to a developer's preference (which might not arrive any time soon or might introduce subtle new bugs, who knows) we could use some framework to make transparent decisions around that Pareto front, no? (Of course there is a best way to do it that will optimize the codebase for a function of productivity, reliability and pleasure. The likelihood and the cost of changes are part of that function. Finding and advocating for it is the task of the most experienced, wisest team member. Less experienced team members may (or may not) understand the wisdom of the better decision in time. But this is just my struggle with postmodernism and relativism and besides the point)