2016/02/21: CodeReview1

[deadok22]

I'll put my review comments of the first iteration here.

The latest commit now is b7fb1d4. Please push a tag named 'code_review_1' to master branch. I'll use this tag to figure out what has changed since last review.

[deadok22]

For the first iteration of code reviews, I'm going to share some recommendations on what should be done to improve your project's code quality.
0. Add a thorough project description to README.md. Otherwise I don't know if the code in this repo does what it's supposed to. Also add instructions for building the project and running it.

1. Write more informative commit messages. Commit history becomes a useful instrument when you try to understand why a design decision was made.
2. Printing stack traces to console directly is a bad practice, especially for a user-facing console application. Choose a logging framework and use it. Note that it can be useful to not only log errors, but also regular program execution - it will aid debugging if something goes wrong.
3. The project can benefit from a single build system for both android and pc parts. It will also aid implementing integration tests, if you're going to write any.
4. Documentation is an important part of any project. I'm not going to require you to write docs to every class and method, or impose any other formal requirements. I want you to write docs where it's not obvious what code is doing. For instance, it's not obvious what Clicker class is for - a better name for it, or at least a couple lines of javadoc can fix that. Another example is in the same class - there's some bit manipulation in it's constructor and you can't easily grasp what it is for - extracting a method, or commenting inline can make reading this code easier.
5. Use constants for literals you use in your code. It greatly improves readability and allows you to maintain references between different parts of your project. I haven't read android part of the project yet, but I can see that pc part defines some protocol which is used by client - if you extract a common library for your protocol, it will be much easier to track changes.
6. There should be no code in the project that has to do nothing with the project itself: example
7. There should be no commented out code blocks. example
8. You should enforce a single naming convention in your project. Here you have fields names starting both with capitals and lowercase letters.
9. Get rid of My*** names. Use meaningful names.
10. Do not expose classes/members unless they're part of API that you're publishing. It's especially true for names like My*** - if you're using those, they should be hidden where it's clear from context what 'My' means.
11. It would be great if you had some unit tests.

[deadok22]

These are some issues I want you to fix. For now I'm not going to rate you because I don't know what this project is and I haven't run it.

If you have any questions - you're welcome to ask them.