182

The spirit of his claim is indeed correct. The point of unit tests is to isolate code, test it free of dependencies, so that any erroneous behavior can be quickly recognized where it is happening. With that said, unit testing is a tool, and it is meant to serve your purposes, it is not an altar to be prayed to. Sometimes that means leaving dependencies in ...


159

The principles stated in "Clean Code" are not always generally agreed upon. Most of it is common sense, but some of the author's opinions are rather controversial and not shared by everybody. In particular, the preference for short methods is not agreed on by everybody. If the code in a longer method is not repeated elsewhere, extracting some of it to a ...


83

Good answer here already, but let me say a word about your butterknife example: though I have no idea what the code does, at a first glance, it does not look really unmaintainable to me. Variables and method names seem to be chosen deliberately, the code is properly indented and formatted, it has some comments and the long methods at least show some block ...


75

If they really are reusable methods / classes, you could write them into a small number of 'Swiss Army Knife' libraries. We do this quite often at my company; we call them framework libraries: Framework.Data - Utilities for working with database queries. Framework.ESB - Standard methods for interacting with our enterprise service bus Framework.Logging - ...


35

I think this comes down to terminology. To many, a "unit test" is a very specific thing, and by definition cannot be have a pass/fail condition that depends on any code outside of the unit (method, function, etc.) being tested. This would include interaction with a database. To others, the term "unit test" is much looser, and encompasses any sort of ...


34

Summary As JacquesB writes, not everybody agrees with Robert C. Martin's "Clean Code". The open source projects that you found to be "violating" the principles you expected are likely to simply have other principles. My perspective I happen to oversee several code bases that adhere very much to Robert C. Martin's principles. However, I do not really ...


32

Haven't watched the full Rich Hickey presentation, but if I understand him correctly, and judging from what he says about the 29-minute mark, he seems to be arguing about types killing reuse. He is using the term "interface" loosely as a synonym for "named type", which makes sense. If you have two entities { "name":"John" } of type Person, and { "name": "...


29

Libraries. Frameworks. Version control. If you've got reusable code, the very last thing you want is for different team members to copy the source code into their project. If they do that, chances are that they'll change a bit here and tweak a bit there, and soon you've got dozens of functions or methods that all have the same name but which each work a ...


28

He is likely referring to the basic fact that an interface can not be instantiated. You can not reuse an interface. You can only implement code that supports it, and when you write code for an interface there is no reuse. Java has a history of providing frameworks of many API(s) that take an interface as arguments, but the team who developed the API never ...


27

C makes it difficult to write generic code. Unlike C++, which gives you templates and virtual functions, C only has 3 mechanisms for writing generic code: void* pointers Preprocessor macros Function pointers void* pointers are far from ideal, since you lose all type safety provided by the compiler, which can result in hard-to-debug undefined behavior ...


27

If I try to make a new method to handle B differently, it gets called out for code duplication. Not all code duplication is created equal. Say you have a method that takes two parameters and adds them together called total(). Say you have another one called add(). Their implementations look completely identical. Should they be merged into one method? NO!!! ...


21

I disagree with the accepted answer for many reasons. In my experience, when I see "miscellaneous" libraries like the accepted answer, they're an excuse to reinvent the wheel (or not invented here(NIH)) - a far greater sin than violating Dont Repeat Yourself (DRY). Sometimes violating DRY can be a reasonable compromise, it is better than introducing tight ...


19

Skew in its most traditional definition means out of alignment (not parallel). Obviously when code is copied and pasted the two copies are identical and parallel. This is not an invariant. Changes made to one copy is not guaranteed to make it to the other copy (due to carelessness or ignorance). Now there are two versions of code existing in two different ...


15

I can not speak for others, but in my own personal experience with C, code duplication has not been much of an issue. Whether this is due to project sizes, or a charmed sample set I can not say. However, there are three rules of thumb that I follow that I think are applicable. In no particular order, they are ... Write for what is needed. Generality can ...


15

I got a couple of projects at github ( http://github.com/jgauffin) which have received some users. What I do is: Examples Developers are lazy. If they can't figure out how to use your code they'll just continue to search after another library. Clear and concise examples are important Documentation When they have started to use your library they'll need ...


15

Since it is in github and is publicly available, can I use the code in my module... NO. ...or should I get the author's written permission? YES. In all 166 nations that are signatories to the Berne Convention, copyright is granted to an author when the work is created. The author holds a monopoly on all copyright rights (creating modifications, ...


15

First thing : A pure JS code in a separate file will be cached, reducing the amount of data transfered on each request. Unless you have a very small, page specific JS code, you shouldn't inline it. Other valid reasons are already pointed in Mike's answer. If you have to pass some values from the server to the JS, what you can do instead of injecting JSP ...


14

I think slide 13 at his presentation (The Value of Values) helps to understand this: Values Don’t need methods I can send you values without code and you are fine My understanding is, Hickey suggests that if I need to, say, double the value you sent to me, I simply write code looking like MyValue = Double(YourValue) You see, ...


14

I have a class used to process customer payments. All but one of the methods of this class are the same for every customer, except for one that calculates (for example) how much the customer's user owes. Two options come to my mind. Option 1: Make your class an abstract class, where the method which varies between customers is an abstract method. Then ...


13

One approach for that is setting up a Wiki for that purpose, and write some high-level docs on what reusable components you have, how you solved a problem etc. The hard part is to get every one in your team to constantly maintain that Wiki. But any other kind of documentation suffers from the same problem. Some of your code may also be good enough to be ...


13

I think it's merely a question of properly naming the extracted method. I'm afraid there is no universal solution and you'll have to do this on a case by case basis. If you are repeating this exact same piece of code in more than 1 place, there is bound to be a meaning to your actions and you need to look hard (may be discuss) to find that meaning and give ...


13

Yes and no. If all you've done is wire up crud apps using some framework specifically to do that, employers will question if that's all you can do - especially if it's an older technology. Likewise, if you spent the past 2 years doing something that would've taken a week if you'd just used Framework X, that doesn't reflect well on you either. Employers ...


13

You should do whatever yields the greater business value in this situation. Writing software is always a trade-off. Almost never are all valid goals (maintainability, performance, clarity, conciseness, security etc. etc.) completely aligned. Do not fall into the trap of those short-sighted people who consider one of these dimensions as paramount and tell ...


13

Reusing code is not about resurrecting old unused and abandoned code and putting it to use. Reusing code is about making the same code fulfill multiple purposes (perhaps within the same project) by providing a useful abstraction that can be (re)applied in other contexts. Old abandoned code may be consulted, but should probably not be resurrected. It ...


13

Many open source libraries do in fact suffer from objectively poor coding practices and are maintained with difficulty by a small group of long-term contributors who can deal with the poor readability because they are very familiar with the parts of the code that they most frequently maintain. Refactoring code to improve readability after the fact is often a ...


12

You do not. Or really, you should not. If you think of app, your server and your website as separate contexts, then it makes sense there to be duplicate structures. Reasons why it might be a good thing: The structures are similar, but not same. Even if 90% of structure is same across all contexts. Its the 10% that will give you massive headaches. Patterns ...


11

For small bits of code -- say a single class with no dependencies -- we tend to just copy and paste the code into projects. This sounds like a violation of DRY, and I'll admit it can be at times. But over the long term it has been much better than having some sort of massive, multi-headed commons project for a few reasons. First, it is just simpler to have ...


11

Actually you are suffering from the top hardest task to do by a programmer - Naming Things. Sorry for such an amature answer but I couldn't resist. You can find that many people suffer from this, even in internet you can find this type of essay. Now if your repetitive code is all together resulting one work and those methods are not being used by other ...


11

we don't want to modify code that could be shared, because that will cause a big regression test impact Above sounds about right to me. The more important is the code, the more it is shared, the higher are quality requirements, the more quality assurance should be involved when it changes. Since your system is implemented in Java, you can see an example ...


10

You need documentation, a proper one. It should be easy to find and navigate. You also need discipline. If there's already a solution provided in your reusable code libraries but the developer chooses to use his own solution instead (without any proper reason), you should revert his solution and tell him to use the existing solution. I also agree with ...


Only top voted, non community-wiki answers of a minimum length are eligible