26

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!!! ...


10

Save me from published junk drawers. If you want to put small, potentially often used piece of code in a shared library then that library needs a good organizing principle. That is, it needs a good name. One that makes clear what goes in it and what doesn't. I do not need a dumping ground that represents nothing other then stuff you decided to extract. Put ...


7

The usual saying that we all read here and there is: All problems can be solved by adding another layer of abstraction. Well, this is not true ! Your example shows it. I’d therefore propose the slightly modified statement (feel free to reuse ;-) ): Every problem can be solved by using THE RIGHT level of abstraction. There are two different problems ...


5

Whenever I see a method where the behavior switches on the type of its parameter, I immediately consider first if that method actually belongs on the method parameter. For example, instead of having a method like: public void sort(List values) { if (values instanceof LinkedList) { // do efficient linked list sort } else { // ArrayList ...


5

There is no right answer to this. In a general sense, you actually have three options: Add an optional parameter, Add a second function with a different name, Add a second function with the same name, ie overload the function. I don't think JavaScript supports the third option, but I'm out of date with that language so may have that wrong. But many ...


3

You have several different ways to tackle this document the project structure An Architecture document with diagrams read.me on your github repository what piece of code does what Code comments on each function that provide intellisense Follow the same pattern for all your code, or all the code in a project. Then you always know where to look. what ...


2

Code reviews and generally talking are good. But I would challenge the underlying assumption. Try not to have shared code at all. Really you only want to write the code thats unique to you. If you have a common library, chances are there is already a 3rd party one that does the job better and is maintain by a bunch of people who; A. arent paid by you. ...


2

There are many ways of achieving this, but one of the most useful is code review, and it's something that's worth doing in an organisation of any size. All committed code should be reviewed by at least one other developer. They then give feedback to the original author, making suggestions on how it should be improved. These remarks may include: possible ...


2

The reusability graal Achieving reusability requires lose coupling: every dependency to other classes makes the reusability more difficult because it adds more constraints. For example if reusing your actuator requires reusing your state and and your commands, which themselves may require to reuse I don't know what, and so on, it may not be so reusable ...


2

I'd choose option 2 for the following reasons: A separately named method reveals the intention better than a boolean parameter that you need to look up to understand what it does. Since you're not modifying any existing behaviour but simply doing something extra at the end, there isn't a good reason to change the original method to take an additional ...


2

Another way to solve it using the Design Patterns Strategy and Factory Method: An interface defines the strategy, in this case, it say that the strategy is write something, without details about what. interface IStrategy { void Write(); } For each variation of the strategy you implement the IStrategy: class StrategyA : IStrategy { //.... } class ...


1

If you follow Bob Martin's ''clean code'', then you might prefer option 2 (as in @David Arno and @casablanca.) Indeed, One function argument is better than two Simple well-named functions are better than complicated, vaguely named Each function should do one and only one thing (ie, single responsibility principle at the basic level) Open-closed principle:...


1

Direct feedback Is there any [..] form of a standard document to help document the project structure, Documentation should be structured in the way that makes the most sense to the people reading it. There is no objectively superior method, other than simply instructing you how to write clearly (which has nothing to do with software development ...


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