5 ms·

This attitude seems a little silly to me—being "extra vigilant, pedantic and strict" about happy-path code would necessarily imply the same about "exception and

This attitude seems a little silly to me—being "extra vigilant, pedantic and strict" about happy-path code would necessarily imply the same about "exception and error paths". Generally speaking, bugs mostly appear in a binary fashion and not in varying degrees—ie your code either reflect expected behavior or doesn't.

reactordev 3y ago
You'd be surprised at how many await's it takes to produce a try/catch. The attitude of being extra vigilant, pedantic, and strict around exception and error paths forces the happy path to be as well defined as it possibly can be given the requirements. It's defensive programming. Assume everything will break in ways you don't know about when writing it. Especially true for async/await code. I don't find it silly. It's like a seasoned sarge telling you not to pull the pin on that baseball object you have in your hand.
- JeffSnazz 3y ago
  > It's defensive programming. This would necessarily presume applying the same attitude towards the happy path—you're describing something short of that. Or to put it a different way: defensive programming necessarily implies a skepticism that you even are sure what the happy/error paths are!
  - reactordev 3y ago
    Oh you definitely apply the same attitude to happy path at the end after scrutinizing the exception/error path options.
    - JeffSnazz 3y ago
      > This is why I am extra vigilant, pendantic and strict when writing or reviewing code that handles exception and error paths. I realize that this is a different person from you, but that's the attitude I am replying to.
      - hnrhn 3y ago
        Perhaps the implication is not "extra vigilant ... [compared to my level of vigilance on the happy path]", but rather "extra vigilant ... [compared to other people I work or have worked with]" The latter is how I read it, because I have definitely worked on teams where the happy path was heavily scrutinised, but error handling was treated as an afterthought, and rarely inspected too closely, leading to anything from error strings copied from another part of the application with names not updated to match the new location to throwing XException but only handling YException, so the XException bubbles up to a much less useful handler.
        deleted 3y ago
        [deleted]
        deleted 3y ago
        [deleted]
        JeffSnazz 3y ago
        I don't tend towards expressing personal comparisons "in public" since they seem both inevitable regardless of the situation and disrespectful to bring up as a topic of interest—not to mention potentially exposing you as incompetent yourself. I guess not everyone else feels the same way. Hell, I'm free now! Everyone I've ever worked with sucks donkey-dick for not coding how I do!
        rimunroe 3y ago
        > I don't tend towards expressing personal comparisons "in public" since they seem both inevitable regardless of the situation and disrespectful to bring up as a topic of interest—not to mention potentially exposing you as incompetent yourself. I guess not everyone else feels the same way. > Hell, I'm free now! Everyone I've ever worked with sucks donkey-dick for not coding how I do! I read it as "extra vigilant ... [because it's natural for people, including me, to focus on the happy path]". I didn't read it as putting down other people you've worked with, holding yourself up as some paragon, OR potentially exposing yourself as incompetent (I'm really not sure how it would do that anyway?). People tend to focus on the happy path. It's good to be aware of that and try to correct it. It doesn't require or imply thinking poorly of other people.
tryfinally 3y ago
As a game developer, I definitely distinguish high-risk and low-risk parts of the code base. There's code that can be allowed to fail, and furthermore, it will eventually fail due to the sheer amount of this code, the development time constraints, the number of possible game states, etc. I don't care that this code rarely fails under some arcane conditions, because this simply causes some button to stop working, some NPC to stop moving, but the game will remain playable. Even if the player notices the bug, they'll just shrug and keep playing. My aim is to make sure that the game recovers and returns to a healthy state after the level/save is reloaded. (Obviously, I'd like to fix/avoid every single possible bug, but it's impossible in practice. You'll have more luck continuously tracking in your head how dangerous the code you're working on is. Also, you rarely have the luxury of being the only programmer on the team. Bugs will happen.) The other kind of code is the core game system stuff, the low level stuff, the error handling stuff, the memory stuff, the pointer stuff. You must pay special attention while working on this code, because failures will straight up crash the process or bring the game into an irrecoverably broken state (eg. all objects stop updating, stuck in some menu, the player never respawns...). Bugs like these are also highly prioritized by management. My update loop needs to be shiny. Such is the reality of working on complex systems (or simple object-oriented programs ;))
- deleted 3y ago
  [deleted]
- JeffSnazz 3y ago
  TBF, I can't name more than a couple dozen sets of game software that I would consider "quality". That shit is generally developed on a deadline and it shows.
  - tryfinally 3y ago
    Well, yes, deadlines are best practice.
berkes 3y ago
In "happy paths" I except some fancy abstractions, allow large dependency trees, complex state-machines or business-logic. I'm "fine" with deeply nested trees of includes, inheritance, modules and whatnot. But I insist the "unknown unknowns" are handled extremely simple, predictable and decoupled. Because those happy paths will fail. And then the exception-path must take over and this must be able to handle it predictable. So no third party error services that I have to call over HTTP (HTTP will fail). No complex logging libraries (dependencies will become outdated). No difficult tracing middleware that has to be configured "just right" (configs will break). And certainly no flows that require a spaghetti-wrangler to follow along.

reactordev 3y ago

You'd be surprised at how many await's it takes to produce a try/catch. The attitude of being extra vigilant, pedantic, and strict around exception and error paths forces the happy path to be as well defined as it possibly can be given the requirements. It's defensive programming. Assume everything will break in ways you don't know about when writing it. Especially true for async/await code. I don't find it silly. It's like a seasoned sarge telling you not to pull the pin on that baseball object you have in your hand.

JeffSnazz 3y ago
> It's defensive programming. This would necessarily presume applying the same attitude towards the happy path—you're describing something short of that. Or to put it a different way: defensive programming necessarily implies a skepticism that you even are sure what the happy/error paths are!
- reactordev 3y ago
  Oh you definitely apply the same attitude to happy path at the end after scrutinizing the exception/error path options.
  - JeffSnazz 3y ago
    > This is why I am extra vigilant, pendantic and strict when writing or reviewing code that handles exception and error paths. I realize that this is a different person from you, but that's the attitude I am replying to.
    - hnrhn 3y ago
      Perhaps the implication is not "extra vigilant ... [compared to my level of vigilance on the happy path]", but rather "extra vigilant ... [compared to other people I work or have worked with]" The latter is how I read it, because I have definitely worked on teams where the happy path was heavily scrutinised, but error handling was treated as an afterthought, and rarely inspected too closely, leading to anything from error strings copied from another part of the application with names not updated to match the new location to throwing XException but only handling YException, so the XException bubbles up to a much less useful handler.
      - deleted 3y ago
        [deleted]
      - deleted 3y ago
        [deleted]
      - JeffSnazz 3y ago
        I don't tend towards expressing personal comparisons "in public" since they seem both inevitable regardless of the situation and disrespectful to bring up as a topic of interest—not to mention potentially exposing you as incompetent yourself. I guess not everyone else feels the same way. Hell, I'm free now! Everyone I've ever worked with sucks donkey-dick for not coding how I do!
        rimunroe 3y ago
        > I don't tend towards expressing personal comparisons "in public" since they seem both inevitable regardless of the situation and disrespectful to bring up as a topic of interest—not to mention potentially exposing you as incompetent yourself. I guess not everyone else feels the same way. > Hell, I'm free now! Everyone I've ever worked with sucks donkey-dick for not coding how I do! I read it as "extra vigilant ... [because it's natural for people, including me, to focus on the happy path]". I didn't read it as putting down other people you've worked with, holding yourself up as some paragon, OR potentially exposing yourself as incompetent (I'm really not sure how it would do that anyway?). People tend to focus on the happy path. It's good to be aware of that and try to correct it. It doesn't require or imply thinking poorly of other people.

tryfinally 3y ago

As a game developer, I definitely distinguish high-risk and low-risk parts of the code base. There's code that can be allowed to fail, and furthermore, it will eventually fail due to the sheer amount of this code, the development time constraints, the number of possible game states, etc. I don't care that this code rarely fails under some arcane conditions, because this simply causes some button to stop working, some NPC to stop moving, but the game will remain playable. Even if the player notices the bug, they'll just shrug and keep playing. My aim is to make sure that the game recovers and returns to a healthy state after the level/save is reloaded. (Obviously, I'd like to fix/avoid every single possible bug, but it's impossible in practice. You'll have more luck continuously tracking in your head how dangerous the code you're working on is. Also, you rarely have the luxury of being the only programmer on the team. Bugs will happen.) The other kind of code is the core game system stuff, the low level stuff, the error handling stuff, the memory stuff, the pointer stuff. You must pay special attention while working on this code, because failures will straight up crash the process or bring the game into an irrecoverably broken state (eg. all objects stop updating, stuck in some menu, the player never respawns...). Bugs like these are also highly prioritized by management. My update loop needs to be shiny. Such is the reality of working on complex systems (or simple object-oriented programs ;))

deleted 3y ago
[deleted]
JeffSnazz 3y ago
TBF, I can't name more than a couple dozen sets of game software that I would consider "quality". That shit is generally developed on a deadline and it shows.
- tryfinally 3y ago
  Well, yes, deadlines are best practice.

berkes 3y ago

In "happy paths" I except some fancy abstractions, allow large dependency trees, complex state-machines or business-logic. I'm "fine" with deeply nested trees of includes, inheritance, modules and whatnot. But I insist the "unknown unknowns" are handled extremely simple, predictable and decoupled. Because those happy paths will fail. And then the exception-path must take over and this must be able to handle it predictable. So no third party error services that I have to call over HTTP (HTTP will fail). No complex logging libraries (dependencies will become outdated). No difficult tracing middleware that has to be configured "just right" (configs will break). And certainly no flows that require a spaghetti-wrangler to follow along.