|
| gorgoiler wrote:
| This seems on the right track. On the notion of _"programming is
| a tool to solve problems that you have in the domain of
| computers"_ though:
|
| Writing a computer program serves two separate purposes: to
| communicate a set of functions to the machine, but also to
| communicate the purpose of these functions to a human. The former
| is for execution and the latter is for code review and, later,
| debugging.
|
| Any old clown can get a computer to do something approximating a
| solution to the problem at hand. If it has bugs then the author
| -- or more likely some other poor sap down the line -- will be on
| the hook to first understand the intent, and then make the code
| match the intent.
|
| In a professional shop you will have code review where this
| "debugging" step happens _first_. Your reviewer will read your
| code to infer your intent and upon agreeing with that, check your
| style and composition for inconsistencies or lack of clarity.
|
| To that extent, a large codebase is akin to a mathematical proof
| where each new module and function represents a lemma on which
| the final proof depends. No serious scientist would present their
| thesis without a progression of isolated and carefully laid out
| lemmas and corollaries, and no serious programmer throws up a
| thousand line function with 15 arguments, global state, and -- if
| in a dynamic language like Python -- inconsistent return types.
|
| Your code is a proof to your reviewer that you are on the right
| track. The fact that it happens to execute without bugs and
| produces the correct output is far less important than the code
| being readable, comprehensible, and consistent as part of the
| larger system.
___________________________________________________________________
(page generated 2022-08-17 23:00 UTC) |