guettli / programming-guidelines Goto Github PK

Hello! 👋🏻
I wanted to discuss this before opening a pull request.

Your guideline has help me tremendously and want to say a big thank for sharing this information free of charge.
However I found some grammatical mistakes and typos on some segments, and I would love to point out a few with their corresponding corrections.

purpuse this typo can be found under this heading make-a-clear-distinction-between-authentication-and-permission-checks

-- purpuse
++ purpose

immideately this typo can be found under this heading FTUE

-- immideately
++ immediately 

Idempotence is great, since it ensures, that it does not do harm if the method is called twice. this issue is found under this segment idempotence-is-great

-- Idempotence is great, since it ensures, that it does not do harm if the method is called twice.
++ Idempotence is great, since it ensures that no harm is done if the method is called twice.

These are the ones I could spot out for now.
Do I have the permission to effect these corrections and many others and then create a pull request? 🙏

https://github.com/guettli/static-site-generators

The winner is Hugo.

When talking about shell scripting I always point people to https://mywiki.wooledge.org/BashPitfalls - it has a comprehensive list of ways you can destroy a machine with seemingly harmless shell scripting. Might want to give a link to that or at least include some common sense practices (set -eu, [[ over [/test and such)?

PS. Very solid guide. How much time did you spend on it?

The current README is way too long. But how to structure it, so that it is easier to read?

I think tags are better than a book-like structure.

This issue is for brainstorming which tags could be usefull.

Feel free to add your ideas.

[snipped]

Maybe you will find this interesting + you might want to include some of the topics in your own guideline: https://github.com/theodesp/stable-systems-checklist

PS. Thanks for the awesome guide :)

I'm misusing issues for a friendly feedback. I agree with you if I can judge at all or I have a similar intuition or believe something could be well-founded (like don't use XY) and the life is short.

a piece of trash in: "Imagine there is be a a Meta"

"Conditionless Data Structures" - Yes. A good example is a donation from "unknown donor" (imagine in a NGO) It allows more clear queries and statistics, but paradoxical more conditions in the code to not allow to update that general "unknown" object by mistake when some information became known later.

Null values: Nulls are also a big problem in Numpy and Pandas. If an integer or boolean field contains a NULL then the column is converted to float numbers, or is invalid without Pandas. Many people consider special rules and values like NaN, -inf, +inf a lapsus in IEEE 754. If a modern float point processor contains such value anywhere in FPU Register Stack then reportedly it still operates twenty times slower until that thrown out.

Constraints x redundancy: I agree. A special case "are historical" data that should be never synchronized, e.g. foreign key to contact on invoice object and a name of subject at the when the invoice was created.

CRD: Delete is also problematic, especially if the object is still used as a foreign key, e.g. a Contact. Update can not be replaced by delete+create then. (The only point where I rather disagree.)

CSV vs Excel: agree. Huge Excel files can be many times slower than the same data in CSV. This can be the only reason to convert, if the same file must be used repeatedly.

Give booleans a "positive" name: That means sometimes to use a default value True (checked box).

Untestable code: I agree: write test or simplify to be testable. I remember my fix to a bug in Django createsuperuser that failed only on Windows if the current user username contained some accent characters. The fix has not been merged because it was essentially untestable (many possible windows versions and regions) The code and fix was simplified to slugify the username only, where everything can either be tested or considered unbreakable.

Don't search the needle...: I like to add a debug condition or debug print to the right place in Django source code in a similar situation. (But maybe I will not know it in next versions and I write to my list: Don't maintain a custom Django db backend :-)

Love your docs (readme friendly to newcomers) !!!
Avoid to get a nerd !!! very important

Thank for sharing this with me.

I agree with you on most topics but in terms of learning python could you elaborate a bit more as to why we should study lower level languages such as C?

Also I have found numerous articles and blog post from people that swear by learning vim or emacs instead of a modern IDE which simplifies and almost dumbs down the role of a programmer and over relying on technology for learning aspects of a language.

Would gladly discuss these thoughts because I am trying to understand people's perspective and know what is the appropriate path for a fully learning roadmap.

Design patterns are indeed overrated, I haven't seen a by the book implementation of a design pattern so far, only bastardizations with a prefix attached to them. How can students learn from these and where should we draw the line?

Any tips on to how I can encourage people to bring their own life into programming? Sports, memories, life and passions? Most people I see code like robots and their code is genuinely boring without any imagination or creativity. I can see flavorful code into someone who is passionate about coding and their own past times.

AFAIK this is not available yet.

Hi I read your guidelines, lots of things I like, some parts I would have liked to know earlier, some parts I don't understand since I haven't encountered them. Which I take as a good sign, the advice giving has happened before the problem.

Anyway, the one thing I disagree about is csv. I like csv because it's an easy format that I can write and parse myself. Reading Excel directly is better but may not be available.

It also means someone is using excel.

Failure on my part to read the csv means there is either something wrong with the data I need to fix anyway or I didn't understand something or both. All are good if they happen when I read the file, as opposed to when I try to use the data.

Anyway thanks for this text, I'm sure it will be useful in the future.

I was born 1076

Should this be 1976?

The README is way to long and not pretty.

This tool could help: https://squidfunk.github.io/mkdocs-material/

https://github.com/guettli/static-site-generators

The winner is Hugo.