I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
Thanks for the post. It is rather long so maybe better as a multi part post but I look forward to going through it more in detail tomorrow after skimming it now. LOL at your Yoda reference. And I like the SOLID etc. you put on there. Going to use those references in my notes.
Regarding dev opinions - using a linter is a great way to get everyone to use the same code style before they submit for code review. You can set it up on your CI that the PR can't even be merged until someone applies the lint fixes and pushes the code.
Regarding the multiple nested if statements - one of the measures around this is "code complexity". Some linters will warn you that you have nested too many levels deep.
Also a bit more of my 2 cents. In my team, if a PR has to go through a
round of changes because it failed code review twice, we make an effort to talk face to face about the PR. Perhaps there is an underlying bad understanding of the problem or inappropriate solution which is better to discuss verbally as at a high level rather than in a few spread out comments that don't make a lot of sense read separately or in the wrong order.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
Regarding linters I can recommend prettier for JS and Black for Python. They will lint your code and even format it for you. Best if you setup VS Code to format on save. :)
They both have sensible defaults and pride themselves on limited config options compared with others like Flake8 for Python.
This is to deliberately prevent devs having to decide (ie argue) should we configure the linter use double or single quotes and semicolons or not and tabs or spaces and where do we wrap and when do we use commas...
The linter tells you what you need to use and you stick to that and move on!
And they give a bit flexibility so you configure them if you want.
See also Bikeshedding which in programming means when you argue about style issues like tabs vs spaces rather than on decisions which affect performance, architecture, business logic, etc. en.wiktionary.org/wiki/bikeshedding
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
Thanks for the post. It is rather long so maybe better as a multi part post but I look forward to going through it more in detail tomorrow after skimming it now. LOL at your Yoda reference. And I like the SOLID etc. you put on there. Going to use those references in my notes.
Regarding dev opinions - using a linter is a great way to get everyone to use the same code style before they submit for code review. You can set it up on your CI that the PR can't even be merged until someone applies the lint fixes and pushes the code.
Regarding the multiple nested if statements - one of the measures around this is "code complexity". Some linters will warn you that you have nested too many levels deep.
Also a bit more of my 2 cents. In my team, if a PR has to go through a
round of changes because it failed code review twice, we make an effort to talk face to face about the PR. Perhaps there is an underlying bad understanding of the problem or inappropriate solution which is better to discuss verbally as at a high level rather than in a few spread out comments that don't make a lot of sense read separately or in the wrong order.
Regarding linters I can recommend prettier for JS and Black for Python. They will lint your code and even format it for you. Best if you setup VS Code to format on save. :)
They both have sensible defaults and pride themselves on limited config options compared with others like Flake8 for Python.
This is to deliberately prevent devs having to decide (ie argue) should we configure the linter use double or single quotes and semicolons or not and tabs or spaces and where do we wrap and when do we use commas...
The linter tells you what you need to use and you stick to that and move on!
And they give a bit flexibility so you configure them if you want.
See also Bikeshedding which in programming means when you argue about style issues like tabs vs spaces rather than on decisions which affect performance, architecture, business logic, etc.
en.wiktionary.org/wiki/bikeshedding
I use Black in python project here locally and in VS Code and in GH Pages
No config. Just defaults.
Makefile