Butterknife: Inquiry regarding library maintainability

[IslamSalah]

Unfortunately I'm still inexperienced enough to write high quality code so I read books addressing that issue like Clean Code by Robert C. Martin and I keep checking code of well-known libraries like this one to improve my skill.

Although this awesome library has been maintained for years which means that it's very unlikely that it isn't on the right path, I found the code in some classes like ButterKnifeProcessor somewhat far from the principles addressed to write clean code – e.g method of hundreds lines of code.

So my question is:
Are the principles of clean code are too restricted and we can do without them as in many libraries like this one? If not how a huge library like this one is being maintained without considering many of these principles?

I'll appreciate any brief clarification. Apologize me if the question seems to be silly from a newbie guy :|

UPD

I asked on stackexchange but will appreciate any very brief answer from the authors.

UPD

If you believe my issue is inappropriate, feel free to close it.

[corjohnson]

How is a huge library like this one is being maintained without considering many of these principles?

I believe that Clean Code is a great approach to building software; but just like any convention, it's more of a guideline than a law. In a perfect world; you'd have the time, energy, and budget to build everything in the most "perfect" way. This is not the reality though.

There's no point in rebuilding a well functioning library to match the principles of clean code. If you have ideas on how to improve it; write up your ideas and maybe fork the code & submit a pull request with the changes. The thing is; people already use this library in a lot of applications. So unless you're suggesting a change that improves upon the existing functionality in terms of something like performance or business value; what's the point of changing it?

At the end of the day I think it's more important to have something functional with a proven history of working well in it's use case.

[IslamSalah]

So unless you're suggesting a change that improves upon the existing functionality in terms of something like performance or business value; what's the point of changing it?

I believe the point of changing is to allow the easy maintenance afterwards. IMHO we don't like systems applying clean code as it looks good or it's something seeking perfection!

As you said, applying these rules has a cost. But It's almost the only way we can maintain huge systems and add new functionalities smoothly.

I believe clean code is like the pedestrian rules, everyone wants to reach their destination as fast as possible. But the rules protect you in the first place.

So my question here is how the great authors ignore many of these rules without being hurdled in maintenance for years?

[corjohnson]

I mean; to piggyback off of your analogy to the rules protecting pedestrians in the first place... Do you ever jaywalk or cross the street when there is no crosswalk? If there are no imminent dangers or cars on the road, it's completely empty... It's much better to take the shortest path.

I think it comes down to complexity & scope. If your project is expecting an ever expanding scope, then you would totally want something that defines a foundation that is easily maintainable. However I think specifically with Butterknife; you're looking at a very specific scope surrounding view & event bindings. The people who are maintaining the library are capable of updating and maintaining the existing functionality.

I would also advise not treating approaches to software development as an absolute truth. Even looking at clean code; there have been a majority of adjustments to how those practices are defined. At the end of the day; you code in a way that the people maintaining and using it understand & can comprehend.

If you're interested; there is a talk from Robert C. Martin from a few years ago when he was still sorta ironing out the concepts of Clean Code compared to what it is today.

https://www.youtube.com/watch?v=QHnLmvDxGTY&index=1&list=PL0t9k9FlHnTki4D06nfKTfO9aw0xaEIwx

[JakeWharton]

Since this library is developed in my free time, the minimum amount of work goes into it to accomplish a goal. So while it's far from unreadable spaghetti code, it's also far from following whatever is inside Clean Code (haven't read it).

Shipping software requires a level of pragmatism. Following every pattern and architecture to the letter is going to create a codebase that is a pain to work in. Having no patterns or architectures is going to create a codebase that is a pain to work in. It's a spectrum. Somewhere in the middle is the right place to live.

Sure those long methods could be refactored, but unless I'm going to be spending a ton of time in them adding features then it would mostly just be a waste of time. I also believe IDEs have become an invaluable tool here in the sense that the ability to navigate and refactor is so much greater than otherwise where you don't need to be as strict.

Finally, development here isn't rapid. It would be a more pressing issue if this method needed to change frequently. It probably changes once a year. Maybe less. As such it would be a waste of my time to refactor this and it also has the potential to introduce bugs. And sure you could argue the bugs things is a lack of testing, and I would agree because, again, I'm doing this in my spare time and testing is also best effort.

I hope that helps answer your questions.