
Some programming principles I have been living by - erikpukinskis
Do as much as possible in one language<p>Do it inside a module with a clearly described interface<p>No modules bigger than 150 lines or so. They should read like a chapter in a book<p>Prune data structures as much as possible at interfaces<p>Code is deployed with a realtime editor<p>Don&#x27;t break the debugger<p>Stick to functions and literals. If you want to use a fancy control structure, it&#x27;s fine, just do it behind a function with an understandable name and a clear interface<p>Address the widest <i>possible</i> market, and use whatever backwards technology you must to make it possible<p>Try to keep things imperative, even if you have to reorganize your functions so it reads well. Only use declarative interfaces where you truly need meta control, like composing things that can&#x27;t just be concatenated, or optimising a pipeline
======
meric
>> Do as much as possible in one language

>> No modules bigger than 150 lines or so. They should read like a chapter in
a book

>> Code is deployed with a realtime editor

>> Address the widest possible market, and use whatever backwards technology
you must to make it possible

I'm going to guess, your one language is javascript? I write Node.js too and
your list is a reasonable list for "A list of Node.js programming principles".

------
TurboHaskal
\- Don't worry about extensibility and configurability.

\- Use sane defaults.

\- Treat bad documentation as a blocking bug.

\- The tool you look for probably exists already and it's not going to get
better just because you rewrite it Rust / Go / Node.

\- Abstraction should make things easier. Abstraction for the sake of
abstraction is obfuscation.

~~~
osullivj
Yep - premature abstraction is just as bad as premature optimisation.

------
osullivj
"Listen to the system". When I'm debugging, I always being all kinds of
preconceptions about possible root causes to any issue. Those preconceptions
often stop me reading and understanding error messages properly. So I take a
deep breath, and try to really read the error messages, and listen to what the
system is telling me.

------
trcollinson
On the face of it, your list seems quite reasonable. I like it. What is your
one language of choice? Do you have any examples you'd share that demonstrate
your principles in action?

------
osullivj
"Evenly distribute complexity". This is hard to do. As a new codebase takes
shape it is hopefully well modularised. But inevitably there will be one or
two modules that become knotty concentrations of complexity. The form of the
code is telling you something about your analysis of the problem space.

------
S4M
Mine (a bit shorter and less committal):

\- Try to have as little side effects as possible

\- Keep the number of data structures I use in the same project as small as I
can.

------
twangist
You must only read books with very short chapters.

------
ely-s
My guiding principle is to code something so that you only have to code it
once.

------
erikpukinskis
p.s. the filesystem is declarative

