Many algorithms in Project Euler do not follow coding styles as mentioned by @dhruvmanila here, or even the standard coding guidelines.
Notes:
- A lot of inconsistencies with the
solution functions (a lot of them aren't named as "solution")
- docstring inconsistencies:
>```docstring```
vs
>```
docstring```
The following are considered to be bad and may be requested to be improved:
>>> x = x + 2 # increased by 2
This is too trivial. Comments are expected to be explanatory. For comments, you can write them above, on or below a line of code, as long as you are consistent within the same piece of code.
But there are places where this isn't practised.
|
print(count) # --> 443839 |
- Python typehints don't seem to be present in the initial problem solutions.
- Filename inconsistencies. example
The list isn't complete.
As a beginner who's looking to either understand/contribute, this makes it a bit difficult.
Many algorithms in Project Euler do not follow coding styles as mentioned by @dhruvmanila here, or even the standard coding guidelines.
Notes:
solutionfunctions (a lot of them aren't named as "solution")But there are places where this isn't practised.
Python/project_euler/problem_30/soln.py
Line 36 in b934da4
Python/project_euler/problem_01/sol1.py
Line 9 in b934da4
Python/project_euler/problem_01/sol2.py
Line 9 in b934da4
The list isn't complete.
As a beginner who's looking to either understand/contribute, this makes it a bit difficult.