Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve code quality - fix security and performance issues, better error handling #613

Merged
merged 31 commits into from Sep 20, 2015
Merged

Conversation

agilob
Copy link
Contributor

@agilob agilob commented Sep 19, 2015

This PR contains commits that improve code quality, fix security, performance issues and fixes really bad/unpredicted code behaviour. Functionality should not change at all. See commits for more.

unclosed input buffer can be used as a vector of DoS attact on the application, cause memory leaks

You can NOT realy on any JRE to automatically close streams and buffers!
- rename methods to follow java code guidelines
- remove misleading comment
- change system out printl to logger
some levels of loggins were too high for their purpose
code formatting changes to follow java code guidelines
logger which doest not lose context of exception
remove unnecessary and stupid comments
comment out code which is never used
fix context for logger in opencellidactivity
this class should be 100% revwritten!!
better naming
improved NPE checking
memory usage optimisation
- better code formatting
- logging exceptions...
better code organisation, less try/catch blocks
@agilob
Copy link
Contributor Author

agilob commented Sep 19, 2015

Guys, what do you do with time saved on:

  • not writing loggers for exceptions

  • not reading compiler warnings

  • not checking for memory leaks

  • not writing private

  • implementing more new bugs for that multi-threading app?

    Gym? Extra dinner?

@agilob
Copy link
Contributor Author

agilob commented Sep 19, 2015

If you did quality and performance checks and do error-handling properly you would have not to do it now...

There are still 2 memory leaks that I didn't bother fixing.

@agilob agilob changed the title [WIP] Improve code quality - fix security and performance issues Improve code quality - fix security and performance issues, better error handling Sep 19, 2015
@SecUpwN
Copy link
Member

SecUpwN commented Sep 20, 2015

@agilob, thank you so much for your huge work here! I've been away for longer than I should have been, life has had a tight grip on me - but luckily I found a new job and I'm working my way back here so that I can continue to add my unicorn comments in the future as well. Enough chit-chat, MERGED! 👍

SecUpwN added a commit that referenced this pull request Sep 20, 2015
Improve code quality - fix security and performance issues, better error handling
@SecUpwN SecUpwN merged commit 625e105 into CellularPrivacy:development Sep 20, 2015
@E3V3A
Copy link
Contributor

E3V3A commented Sep 21, 2015

And why are you wasting your time and ours, rewriting all the log Tags without even consulting us why we changed them in the first place? You seem to spend considerable time "fixing" things that is working... It would have been more appreciated if you can look at the issues already filed.

@E3V3A
Copy link
Contributor

E3V3A commented Sep 21, 2015

And Sec, why do you just merge stuff without looking at the code or at least asking for a second opinion?

@E3V3A
Copy link
Contributor

E3V3A commented Sep 21, 2015

This is really pissing everyone off. You've essentially removed every piece of code that is still work in progress, in addition to reformatting everything to your own taste without any thoughts or respect of why we have the formatting we do...

@agilob
Copy link
Contributor Author

agilob commented Sep 21, 2015

You've essentially removed every piece of code that is still work in progress

Sorry, do you know what master branch is? It's dedicated for stable code that passed review process, test and is production ready, 3/4 of classes in this project should be removed and rewritten from scratch.

It would have been more appreciated if you can look at the issues already filed.

I'm not a developer of this project, I don't have contributor status, I don't even follow this project. I am a technical user of this project and I fixed what I found necessary to fix.

Why do you invent your own logging paradigms? That are not efficient, are misleading (class named XX presents itself as YY!), not only loggers but own "standard" of comments that is it not even similar to javadoc or doxygen? This is just stupid and puts people off developing as it makes impossible to use any IDE with auto formatting. About formatting, why do you mix k&r, c++ and java coding standards? If you don't bother following globally known by beginners java coding style, give astyle a try (or try using an IDE like IDEA or Eclipse). It's easy and does formatting job for you. Why do you mix C style (lack of encapsulation, static global booleans in non-static class, static protected threads?!, static thread handlers (I didn't bother fixing it, I left if for you - DoS vulnerability and memory leak, find them), on inefficient wrapper for SharedPreferences? Do you know what lint or sonarqube is? It's finds elementary-level bugs in your code for you.

Remember when due to lack of time I posted you 5 exceptions? 4 of them are fixed here, two are related to race conditions which happen on slower devices. You just closed the issue like an asshole. I recommend you using ACRA or anything else similar, you will be flooded by reports with same details I provided you there and no contact back to a user! It's awesome, makes you think before you commit untested and not analysed shit.

You want a code review now? Did you make any before? Did you read that syntactically broken XML I found a few days ago, which is in repo for months (if you compile code with show warnings option , compiler will point you there - it's really easy!) Who did a code review of this e8e3769? I bet no one because no one who works with git or java would never let this commit be merge to master, or maybe you pushed it directly to master? Is it egoistic? Does it introduce vulnerabilities? Is it low quality code? Did you know not to push white-space changes and commented out code to git? It's just misleading, increases repository size, makes it harder to find who pushed bugs to master and who accepted it.

If you think this PR should be reverted, do it, you have access to do it so and please don't contact me about this issue again, we don't have to waste each others time.

@E3V3A
Copy link
Contributor

E3V3A commented Sep 22, 2015

@agilob

...3/4 of classes in this project should be removed and rewritten from scratch.

As long as you don't do it. We already know that, and its all WIP. Deleting WIP code you think is dumb or useless is not how to do it.

I'm not a developer of this project, I don't have contributor status, I don't even follow this project.

That's exactly why you shouldn't remove or edit code you don't know what it is for, or what its status is.

Why do you invent your own logging paradigms? That are not efficient, are misleading (class named XX presents itself as YY!), not only loggers but own "standard" of comments that is it not even similar to javadoc or doxygen?

This is not a standard hello-world project conforming to Googles out-of-their-ass guidelines and imperialistic IDE/UI/UX designs. There are specific reasons why we spent a lot of time making our own logtags. First of all for readability and clarity, second for automation and easy finding the code where there are bugs, if you've ever bothered to look at the logcat from command line, you know 2 things; 1) It's fucking impossible to know what app produced a specific log entry without having the PID on the live system. 2) The log TAGs have a size limit of 23 characters, and if you bothered counting, we exceed these quite often. With our tags, a simple ...|grep "AIMSICD" returns everything!

Why do you mix C style (lack of encapsulation, static global booleans in non-static class, static protected threads?!, static thread handlers (I didn't bother fixing it, I left if for you - DoS vulnerability and memory leak, find them), on inefficient wrapper for SharedPreferences?

Thank you that explains you philosophy very well. Where you can actually do something right, you don't bother.

Remember when due to lack of time I posted you 5 exceptions? 4 of them are fixed here, two are related to race conditions which happen on slower devices. You just closed the issue

We asked you repeatedly to get back to us with more details, and there were silence, so yes we closed it.

You want a code review now? Did you make any before? Did you read that syntactically broken XML I found a few days ago, which is in repo for months (if you compile code with show warnings option , compiler will point you there - it's really easy!) Who did a code review of this e8e3769? I bet no one because no one who works with git or java would never let this commit be merge to master, or maybe you pushed it directly to master?

I completely agree with you here. I'm actually totally fed up with this project exactly for this reason. I've been trying to have code review and getting people involved in the quality, but since we only have half a developer at any one time, that is not possible. Result is shit code hacked together and heedlessly "fixed" beyond any logic or scrutiny, which is exactly why I'm having this discussion with you. (And yes that code snippet was reviewed by @banjaxbanjo .)

Did you know not to push white-space changes and commented out code to git? It's just misleading, increases repository size, makes it harder to find who pushed bugs to master and who accepted it.

It's not that black and white. Our biggest problem is that our code lacks comments and detailed functional diagram. The recent changes to the DB at a time when people and devs don't have time, is making things much worse. The DB migration is still not finished as the queries are not recognizing linked tables.

If you think this PR should be reverted, do it, you have access to do it so and please don't contact me about this issue again, we don't have to waste each others time.

I think it should be reverted, not because you didn't put a lot of work into this, but because you lack insight to what the stuff you changed and reformatted, was/is meant for. Instead of making many small PRs fixing specific details, you decided to make one huge PR, that is trying to fix too many things concurrently while unknowingly breaking a bunch of stuff which will be impossible to find since you decided to remove comments and code, or anything else that can be useful in a code review.

Remember: Less is more! = One fix, one PR.

@SecUpwN
Copy link
Member

SecUpwN commented Sep 22, 2015

And Sec, why do you just merge stuff without looking at the code or at least asking for a second opinion?

Great, and now I feel bad again. I've been away for like ages, had a very hard time coming back and now people like @agilob who essentially put so much love into our app and work on the repo get blamed again for doing anything. Not cool! Let us NOT continue this discussion here, please. I think we all got the point now: Smaller pull requests are better and I will from now on ALWAYS make sure to request some sort of confirmation into each PR before merging it. Additionally, I turned on master branch protection in order to avoid merging without triple checks. Will help us much in the long run.

I would like to keep the work done here though. We really ought to make this repo a place where standards get settled and developers feel comfortable. Would you PLEASE do me the favor and give the latest Buildozer build a test? Did anything change to the worse? Works smooth as butter over here! @He3556 what are your test results - anything to add? Thanks for staying calm, especially @E3V3A.

@He3556 He3556 assigned He3556 and unassigned He3556 Sep 22, 2015
@He3556
Copy link
Collaborator

He3556 commented Sep 22, 2015

I get errors about "Missing Translation" since we are working on the translations. Sorry i am good in ignoring errors as long as the App compiles and runs on the phone. Everybody should know about that errors anyway...
But since sunday there is another error, so i could not send the new apk to you.
I will try to talk to @agilob - i am sure we could fix it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants