New answers tagged

1

It's all about separation of concerns. (ok, not all about it; this is a simplification). This is fine: function initializeUser(name, job, bye) { this.username = name; this.occupation = job; this.farewell = bye; this.gender = Gender.unspecified; this.species = Species.getSpeciesFromJob(this.occupation); ... etc in the same vein. } ...


4

The point about splitting functions is all about one thing: simplicity. A reader of code cannot have more than about seven things in mind simultaneously. Your functions should reflect that. If you build too long functions, they will be unreadable because you have much more than seven things inside your functions. If you build a ton of one-line functions, ...


12

Any time you feel the need to write a comment to describe what a block of text is doing, you have found an opportunity to extract a method. Rather than //find eligible contestants var eligible = contestants.Where(c=>c.Age >= 18) eligible = eligible.Where(c=>c.Country == US) try var eligible = FindEligible(contestants)


1

The "right" answer, according to the prevalent coding dogmas, is to split large functions into small, easy to read, testable and tested functions with self documenting names. That said, defining "large" in terms of "lines of code" can seem arbitrary, dogmatic, and tedious, which can cause unnecessary disagreements, scruples, and tension. But, fear not! ...


1

Pretty much depends on what your // Logic Here is. If it's a one-liner, then probably you don't need a functional decomposition. If, on the other hand, it's lines and lines of code, then it is much better to put it into a separate function and name it appropriately (f1,f2,f3 does not pass muster here). This is all have to do with human brains on average ...


6

DRY - Don't repeat yourself - is just one of several principles that have to be balanced. Some other that come to mind here are naming. If the logic is convoluted not obvious to the casual reader, extraction into method/function whose name better encapsulated what and why it is doing it it can improve program readability. Also aiming for less than 5-10 ...


40

I think function naming is very important here. A heavily dissected function can be very self-documenting. If each logical process within a function is split out into its own function, with minimal internal logic, then the behavior of each statement can be reasoned out by the names of the functions and the parameters they take. Of course, there is a ...


86

The rationale behind splitting functions is not how many times they will be called, it's keeping them small and preventing them from doing several different things. Bob Martin's book Clean Code gives good guidelines on when to split a function: Functions should be small; how small? See the bullet bellow. Functions should do only one thing. So if the ...


1

As of now you have one ModelDevice class (Device in the model package). What if you have another such ModelDevice for a different classification? The problem may still persist and the overheads will also continue to increase. Though for the time being you may find that renaming classes be of some good help, for a long run the suggested alternate is to go ...


8

Use the package name. This type of problem is precisely why Java uses the package naming convention that it does. It prevents these sorts of problems, whether it's two teams in the same company or two teams on opposite sides of the earth.



Top 50 recent answers are included