You are suffering from a biased sample. You say you check code of "well-known" libraries. Well, the libraries that collapsed under their own weight because they weren't following best practices aren't "well-known", they vanished into obscurity.

@Ewan yes sure. check butterknife

oof that is bad. but its not a particularly long lived. how are you judging its popularity

I think it's one of the most know libraries in android. I saw it almost every where. It also has around 21k stars on github.

Have you checked e.g. the Linux sources?

The primary measure for a piece of software's value isn't how "clean" the code is, it's how well it fulfills some particular task. While some people like to write software for the sake of just writing something, for most people, the code is just a means to an end.

No one disagrees with you. The question is how to maintain poor code for years? Why didn't it have been cleaned over those many iterations of evolving?

If you are following that book as your guide, you are not producing clean code. So your whole point of reference is flawed.

@FrankHileman I'm totally open to accept an opposite point of view. Could you please clarify more why it's a flawed reference?

@IslamSalah: I would not give too much about such a simplified statement. "Clean Code" is IMHO a good book when you take some of Bob Martin's recommendations with a grain of salt. But Frank can have his opionion about it, that's fine.

@IslamSalah. Is there any evidence (or reference) that "Clean Code" is the only way to maintain a codebase? I sincerely doubt that. Maybe "Clean Code" is not that relevant for open source projects, but instead other factors are more important for the lifetime and maintainability of an open source project. For example: an active maintainer, active users, etc?

If you look for references to "clean code" on this site, you will surely find a few that are not praising the book, but wondering how a huge amount of superfluous code qualifies as "clean."

The cynical answer to your question would be, those that follow the book religiously, don't write open source libraries, or they are spending all their time arguing about the book... instead of writing code.

@IslamSalah a lot of the reason is that you don't change something that works because you're likely to break it.

@immibis: your forgot to complete your sentence with "... because you did not write enough automatic tests"

@IslamSalah, for someone who is new to the industry, (presumably) in a junior role, "Clean code" is fine. I wish all our juniors would follow that approach, and I am more than willing to discuss when and where they've overdone it come review time. It's true that following the book to the letter leads to sub-optimal results, but that's nothing compared to what happens if you disregard its contents entirely. Developers with 20+ yrs experience nitpicking over the the finer points are not helpful when you just start out, this book is.

It's also possible that the developer on the included example was following "RFP" - Make it Right,Make it Fast, Make it Pretty. Looking at the linked code, my read of it is that it was written by someone who knew exactly what they needed, knew what they were doing, and wanted to get it working first - the code is in my opinion not bad and is excellently primed for a typical "Clean Code" refactoring (note the whitespace between sections in the long methods, most of the monolithic stuff is still very cleanly delineated, etc). Bearing in mind that this is open-source, especially at the start...

...cont'd the developer's focus will be on getting something that works, as opposed to something that adheres to (albeit good) principles. And the cool thing in this case is, since it's open source, you yourself are free to pull this, apply what you know to refactor it, and submit it back for consideration :) :)

The premise of the question (that long-maintained open-source projects must inherently adhere to one particular book author's notion of best practices) is completely false and I don't know where you got it from. Could you expand on the premise of your question, please?

@Doc Brown: "... because you did not write enough automatic tests" even with a lot of automatic tests, changing working code can introduce subtle bugs that are not detected by the tests. Changing working code is always a risk, even when using automatic tests.

@Giorgio: so since we cannot guarantee refactorings to be bug free, even with lots of tests, we will always better off to add one block of code after another to an existing method, until it crosses a 500 lines limit? Does not convince me.

@DocBrown: I did not say that code should never be changed (I do not see such a sentence in my comment). I agree that having automatic tests helps to change code, but nevertheless you should be aware that you are breaking something that was working to build something new. Being inflexible and never change anything leads to the problems you have described. Being overconfident because you have automatic tests and change code too often can produce code that is never really stable. IMO the best solutions lie between these two extremes.

Argh. So much bikeshedding.