Programming lesson #5
When logic becomes too complex to solve mentally while coding, writing the requirements and inputs on paper and coming up with pseudocode is a good approach.

  • 7
    shouldn't you be doing that before anyway?
  • 2
    For some reason I almost never do that. Seems I'm "weaker" if I do that. I know it's stupid, but idk why I think this way.
  • 3
    That's what tdd does by default
  • 3
    @netikras well yes and no.
    Tdd contains the expected result for a unit of work, not how to get to it.

    For planning I find a big ass whiteboard and work through it before I touch a line of code when it's going to be a complex matter.

    Know what you're trying to achieve before you set out to achieve it, otherwise it'll bit your ass halfway through when you miss something.
  • 5
    @C0D4 Depends on how you do TDD.

    1. create an empty test method
    2. write pseudocode with method names:

    3. go and implement each method in the same manner: pseudocode method names -> implementation -> pseudocode -> implementation -> etc.

    it's like pseudocode-driven-tdd :) It makes building new features very easy as you
    1. define your end goal (test method)
    2. define steps required to achieve that goal
    3. define steps to achieve those steps
    4. ↑↑ -- repeat until you have no pseudocode to write and end up with actual code.

    I still find whiteboard useful for planning at larger scale
  • 3
    @netikras ah, yea I usually just plan it out, write up the unit tests with expected results (hard coded to begin with) then as the the code progresses adjust the tests to work with actual data.

    But yea, it really comes down to how you do things.
  • 4
    I'm just sorta amazed that this is a programming tip.

    What's the alternative — try random shit until it looks right when you squint?
  • 3
    @halfflat Your last sentence is my motto. Did I do it wrong all these years?
  • 1
    I have learned that is the most complicated logic situations you need to ask questions first. This is not a time saver (well in the long run perhaps and definitely for the end user, but not for you).
    Does this logic truly represent the real world? (Convoluted reasons with a lot of "might" and "will" in it)
    Why is it this so complex?
    Is there a better way to solve the problem? (Look at how these things are solved normally)

    Basically getting to the simpler solution is the right way to do it. It's bloody hard though and often requires process changes.
  • 2
    @halfflat that's my approach with JavaScript... :-p
Add Comment