vzccristian/pyro4bot

PYRO4BOT Developing Project

pyro4bot

PYRO4BOT Developing Project

Documentation under construction. We are working on it...

pyro4bot's Issues

Style enhancements

There are several things that should be cleaned up:

• Naming convention. Currently the project mixes camelCase, nocase, snake_case, Weird_Case. The project should pick one and only one of these to make it easier to work with the project. Python recommends to use snake_case, so that's probably what should be used.
• Spaces. Sometimes there's a space after commas, or other operators, but sometimes there isn't. It's even mixed up in calls like cv2.GaussianBlur(mask, (5,5),0). Be consistent here too, and always leave a space like cv2.GaussianBlur(mask, (5, 5), 0). Same applies to things like moments['m10']/m00 instead moments['m10'] / m00 and so on, or leaving a space after the # in comments. An empty new line to separate methods is nice too, unnecessary space when indicating a subclass, or even between the : and a condition on if's.
• Indentation. Most places use 4 spaces, but inside methods, 2 are used. Why the mix?
• Comparing with None. Using != and == is bad practice, and x is not None and x is None should be used instead.
• while True: pass. This is a CPU burner. Consider adding a small sleep(...) or an input(...), so that Enter stops the script.

If someone were to work on this, since it's necessary to modify everything, other people should be aware and stop their work on a certain file while it's being cleaned up. Otherwise, a merge conflict will occur on the whole file, and that's not something anybody wants.

Consider looking at https://learnxinyminutes.com/docs/python3/ to get a glance on how to write clean, consistent code.

Move examples to a separate folder

The root folder has a lot of *.py and *.json files that are clearly usage examples. Consider moving all of these to an examples/ so the structure remains clean, and things don't get mixed up.

Git usage

git is a powerful tool, but one must know how to use it. It enforces developers to write a commit message not without a reason, it's very important to know the changes introduced by a commit without the need to read potentially hundreds of lines. This is why writing short and useful commit messages is important. If the commit messages are "fixes", "working", "sockets" and so on, that's nearly as useful as versioning the project with .zip files instead. A mess.

Branches are also powerful if used correctly, and they should have descriptive names as well. Currently there's developing, a_developing and c_developing with "This branch is 14 commits ahead, 13 commits behind developing.". Why did it diverge so much, and why hasn't the work been done in developing too? What features is each branch working on? Again, current commit messages don't help much.

While you should take the advices described here with a grain on salt, the https://chris.beams.io/posts/git-commit/ article is a good read on how to write git messages properly, and in a consistent way.

Documentation

Since this project is aimed at educational purposes, it's really important to have everything documented. A new comer (like me) will need to invest a considerable amount of time only to get used to the project structure if they were to join the team and work being aware of everything.

There should be at least a more detailed description in the README.md detailing what this project is for and what it's aimed at. Ideally, a Project Structure section that details what every folder and subfolder/module does. The names used may not be obvious at first glance.

Of course, every file and method should have a docstring to know what it does, and what types it accepts for the parameters. Although it's possible to use natural language, in the future, one may want to use http://readthedocs.org/ to host the documentation, and Sphinx or similar to build it (which in turn uses these docstrings automatically).

Ideally, the __init__.py inside each module should also have a description on what it is for.