Code cleaning/refactoring
See original GitHub issueI’m looking through stingray’s code and I saw some things I think we should avoid.
utils.py has 2 private methods which are used in io.py file
Not all imports are at the top of file
Sometimes between operators are spaces sometimes not:
1+2
vs 1 + 2
(I prefer second version)
I know that issues like that are not really important, but might be copied bu other contributors and more time consumed as a huge “problems”
Let me know if it should be “fixed” I will try to do it.
Issue Analytics
- State:
- Created 8 years ago
- Comments:9 (6 by maintainers)
Top Results From Across the Web
Clean code
The main purpose of refactoring is to fight technical debt. It transforms a mess into clean code and simple design. Nice! But what's...
Read more >Clean Code and Refactoring techniques | by Alana Brandão
Clean Code · Give to variables, methods, or other attributes in the code good meaningful names. · Create small methods. · Avoid repetitive...
Read more >Clean Your Code - Code Refactoring Best Practices
Code refactoring is a method in software development that involves cleaning and restructuring existing code without changing its function.
Read more >The “Must” Foundations to Improve your Python Code and ...
Cleaning, Refactoring, and Modularity: The “Must” Foundations to Improve your Python Code and Career. How some code habits can bring your ...
Read more >Clean Coding and Refactoring
The second golden rule is: learn to change the structure of your code without changing its external behaviour (this is called refactoring). This...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@TomaszKolek: I think the reasoning for not having all imports at the top of the file could be, in some cases, imports of optional dependencies. Say you want to use the class
Lightcurve
, but you might not want to plot them, there’s not necessarily a reason for you to importmatplotlib
, so it could be an import in the method that uses it. I don’t actually know whether that’s a standard thing to do? Same for some of the tests.I agree we should avoid it wherever possible, but I’m okay with it for optional package dependencies we don’t want to strictly enforce.
I agree @evandromr. Most of the points raised by @TomaszKolek have been addressed, sometimes without specifically referring to this Issue. I close this and we will reopen if needed. Thanks @TomaszKolek!