Skip to content
This repository has been archived by the owner on Nov 3, 2018. It is now read-only.

Code inspections #23

Open
Vasar007 opened this issue Aug 27, 2018 · 0 comments
Open

Code inspections #23

Vasar007 opened this issue Aug 27, 2018 · 0 comments

Comments

@Vasar007
Copy link
Member

Vasar007 commented Aug 27, 2018

Intro

Here I wrote about some code issues that I had found.

First of all, I would like to write about most common code and doc issues:

  • Need to split lines and leave only 79 characters per line;
  • There are many mistakes in English words and sentences;
  • Variable names must be self-describing;
  • There are lots of magic constants and strings;
  • As for me, all modules have complex logic which very hard to understand. I believe that you can refactor the code and simplify it;
  • There is no information about the format of the input data and its types anywhere (at least you should have this information in your wiki or other docs sources);
  • Need to group methods in classes or in modules if you do not want to work with OOP.

And that's result of my code inspection file by file.

analytics/parser/utils.py

  • Very simple work with logging, need to add some additional flags to avoid mixing with possible third-party loggers or global django logger;
  • Need to separate logging config from code to config file;
  • There are some variable names which shadow built-in types (example: dict);
  • Also during whole file there are lots of lines in global namespace;
  • LinkFinder is not shadow data from other classes, internal methods and fields user can get with such example:
class A:
    def __init__(self):
        self.__v = 42

    def __foo(self):
        print("Call foo")


if __name__ == "__main__":
    a = A()
    a._A__foo()
    print(a._A__v)
  • LinkFinder.mining method contains multiple if-statements with same condition.

analytics/parser/main.py

  • It would be great to avoid global variables and encapsulate them in a class;
  • parse method contains 4 (4, Carl!) nested for-loops! Does anyone want to say that it's not a bad thing?

analytics/finder/main.py

  • Another file with lots of nested loops, mmm...
  • I liked the name of the modules in the imports, but it is better not to do so.

analytics/utils_backend.py

  • It would be better to specify possible exceptions instead of catching all exceptions;
  • You should use logger for django instead of printing messages to stdout;
  • Oh, you left the password for uploading files in the code, NICE! (also you left SECRET_KEY in django settings)
  • os.remove method can throw exceptions but you do not process them.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant