kristofer revised this gist . Go to revision
1 file changed, 1 insertion
bad-habits.md
| @@ -24,4 +24,5 @@ bicycle is OK if it is your personal project and you just want to learn but othe | |||
| 24 | 24 | And Hey, you can do worse than following some these ideas: [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html) | |
| 25 | 25 | ||
| 26 | 26 | You might find this useful: [The Hitchhiker’s Guide to Python - code style](https://docs.python-guide.org/writing/style/) | |
| 27 | + | ||
| 27 | 28 | And never **forget** our dear old friend: [PEP 8](https://peps.python.org/pep-0008/) | |
kristofer revised this gist . Go to revision
1 file changed, 1 insertion
bad-habits.md
| @@ -23,4 +23,5 @@ bicycle is OK if it is your personal project and you just want to learn but othe | |||
| 23 | 23 | ||
| 24 | 24 | And Hey, you can do worse than following some these ideas: [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html) | |
| 25 | 25 | ||
| 26 | + | You might find this useful: [The Hitchhiker’s Guide to Python - code style](https://docs.python-guide.org/writing/style/) | |
| 26 | 27 | And never **forget** our dear old friend: [PEP 8](https://peps.python.org/pep-0008/) | |
kristofer revised this gist . Go to revision
1 file changed, 1 insertion, 1 deletion
bad-habits.md
| @@ -23,4 +23,4 @@ bicycle is OK if it is your personal project and you just want to learn but othe | |||
| 23 | 23 | ||
| 24 | 24 | And Hey, you can do worse than following some these ideas: [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html) | |
| 25 | 25 | ||
| 26 | - | ||
| 26 | + | And never **forget** our dear old friend: [PEP 8](https://peps.python.org/pep-0008/) | |
kristofer revised this gist . Go to revision
1 file changed, 1 insertion
bad-habits.md
| @@ -21,5 +21,6 @@ Either put X spaces (which is what most IDEs do these days) or 1 tab in place of | |||
| 21 | 21 | - Not using popular and well tested libraries and services and re-inventing the | |
| 22 | 22 | bicycle is OK if it is your personal project and you just want to learn but otherwise is BAD. | |
| 23 | 23 | ||
| 24 | + | And Hey, you can do worse than following some these ideas: [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html) | |
| 24 | 25 | ||
| 25 | 26 | ||
kristofer revised this gist . Go to revision
No changes
kristofer revised this gist . Go to revision
1 file changed, 8 insertions, 8 deletions
bad-habits.md
| @@ -5,20 +5,20 @@ related to Python but are considered to be bad practices in most of the language | |||
| 5 | 5 | ||
| 6 | 6 | - No comments is bad — people forget and you should comment your code. Describe **why** not _how_. | |
| 7 | 7 | Explain the **intent behind the code**. | |
| 8 | - | - Too many comments is also bad — you should feel the border line. | |
| 8 | + | - Too many comments is also bad — you should feel the border line at column 80. | |
| 9 | 9 | - No abstractions is bad — they didn’t develop Python for you to write Assembly-style wall of | |
| 10 | 10 | code with no functions and/or classes. Copy-pasting your code is **bad** — use functions when you | |
| 11 | 11 | catch yourself doing it. | |
| 12 | 12 | - Too many if/else closures is bad — if that thing goes into the 6th(!) tabulation level, you know | |
| 13 | - | something isn’t right. | |
| 13 | + | something isn’t right. (Where _are_ your functions??) | |
| 14 | 14 | - Not separating logically separate blocks by spaces and empty lines is BAD — one more time, | |
| 15 | - | don’t make it look like a dead wall, spread things out! | |
| 16 | - | - Bad variables and function names are bad — _you will be surprised how many comment-writing you | |
| 17 | - | can avoid when you start naming your functions well…_ | |
| 15 | + | don’t make it look like a dead wall, spread things out! (Empty lines are _free_.) | |
| 16 | + | - Bad variables and function names are bad — _you will be surprised how many comments you | |
| 17 | + | can avoid when you start **naming your functions well**…_ | |
| 18 | 18 | - Mixing soft and hard tabs is bad — choose one side. | |
| 19 | - | Either put X spaces (which is what most IDEs doo these days) or 1 tab in place of those X spaces. | |
| 20 | - | Do not mix them up. Or expand your tabs and never think about it. | |
| 21 | - | - Not using popular and well tested libraries and services and inventing the | |
| 19 | + | Either put X spaces (which is what most IDEs do these days) or 1 tab in place of those X spaces. | |
| 20 | + | - Do not mix them up. Or expand your tabs and never think about it. | |
| 21 | + | - Not using popular and well tested libraries and services and re-inventing the | |
| 22 | 22 | bicycle is OK if it is your personal project and you just want to learn but otherwise is BAD. | |
| 23 | 23 | ||
| 24 | 24 | ||
kristofer revised this gist . Go to revision
1 file changed, 22 insertions, 8 deletions
bad-habits.md
| @@ -1,11 +1,25 @@ | |||
| 1 | - | Just gonna throw a list at you. Also, be aware that some of the things are not actually | |
| 1 | + | ## One More List of Bad Habits | |
| 2 | + | ||
| 3 | + | Also, be aware that some of these things are not actually | |
| 2 | 4 | related to Python but are considered to be bad practices in most of the languages (like Java). | |
| 3 | 5 | ||
| 4 | - | - No comments is bad — people forget and you should comment your code. | |
| 6 | + | - No comments is bad — people forget and you should comment your code. Describe **why** not _how_. | |
| 7 | + | Explain the **intent behind the code**. | |
| 5 | 8 | - Too many comments is also bad — you should feel the border line. | |
| 6 | - | - No abstractions is bad — they didn’t develop Python for you to write Assembly-style wall of code with no functions and/or classes. Copy-pasting your code is bad — use functions when you catch yourself doing it. | |
| 7 | - | - Too many if/else closures is bad — if that thing goes into the 8th tabulation level, you know something isn’t right. | |
| 8 | - | - Not separating logically separate blocks by spaces and empty lines is BAD — one more time, don’t make it look like a dead wall, spread things out! | |
| 9 | - | - Bad variables and function names are bad — you will be surprised how many comment-writing you can avoid if you start naming your functions well… | |
| 10 | - | - Mixing soft and hard tabs is bad — choose one side. Either put X spaces or 1 tab in place of those X spaces. Do not mix them up. Or expand your tabs and never think about it. | |
| 11 | - | - Not using popular and well tested libraries and services and inventing the bicycle is OK if it is your personal project and you just want to learn but otherwise is BAD. | |
| 9 | + | - No abstractions is bad — they didn’t develop Python for you to write Assembly-style wall of | |
| 10 | + | code with no functions and/or classes. Copy-pasting your code is **bad** — use functions when you | |
| 11 | + | catch yourself doing it. | |
| 12 | + | - Too many if/else closures is bad — if that thing goes into the 6th(!) tabulation level, you know | |
| 13 | + | something isn’t right. | |
| 14 | + | - Not separating logically separate blocks by spaces and empty lines is BAD — one more time, | |
| 15 | + | don’t make it look like a dead wall, spread things out! | |
| 16 | + | - Bad variables and function names are bad — _you will be surprised how many comment-writing you | |
| 17 | + | can avoid when you start naming your functions well…_ | |
| 18 | + | - Mixing soft and hard tabs is bad — choose one side. | |
| 19 | + | Either put X spaces (which is what most IDEs doo these days) or 1 tab in place of those X spaces. | |
| 20 | + | Do not mix them up. Or expand your tabs and never think about it. | |
| 21 | + | - Not using popular and well tested libraries and services and inventing the | |
| 22 | + | bicycle is OK if it is your personal project and you just want to learn but otherwise is BAD. | |
| 23 | + | ||
| 24 | + | ||
| 25 | + | ||
kristofer revised this gist . Go to revision
1 file changed, 11 insertions
bad-habits.md(file created)
| @@ -0,0 +1,11 @@ | |||
| 1 | + | Just gonna throw a list at you. Also, be aware that some of the things are not actually | |
| 2 | + | related to Python but are considered to be bad practices in most of the languages (like Java). | |
| 3 | + | ||
| 4 | + | - No comments is bad — people forget and you should comment your code. | |
| 5 | + | - Too many comments is also bad — you should feel the border line. | |
| 6 | + | - No abstractions is bad — they didn’t develop Python for you to write Assembly-style wall of code with no functions and/or classes. Copy-pasting your code is bad — use functions when you catch yourself doing it. | |
| 7 | + | - Too many if/else closures is bad — if that thing goes into the 8th tabulation level, you know something isn’t right. | |
| 8 | + | - Not separating logically separate blocks by spaces and empty lines is BAD — one more time, don’t make it look like a dead wall, spread things out! | |
| 9 | + | - Bad variables and function names are bad — you will be surprised how many comment-writing you can avoid if you start naming your functions well… | |
| 10 | + | - Mixing soft and hard tabs is bad — choose one side. Either put X spaces or 1 tab in place of those X spaces. Do not mix them up. Or expand your tabs and never think about it. | |
| 11 | + | - Not using popular and well tested libraries and services and inventing the bicycle is OK if it is your personal project and you just want to learn but otherwise is BAD. | |