Hot answers tagged

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


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


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)


7

The point that you should be aiming for with such tests is that as many of them as possible should be interacting with a mock of the database, rather than the database itself. The standard way to achieve this is to inject a DB access layer into the logic you are testing here, using interfaces. That way, the test code can create in-memory data sets prior to ...


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


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


4

Besides the fact that this is an integration test as opposed to a unit test, the operations you describe typically go in Setup and/or Teardown methods. Frameworks like nUnit allow one to decorate class methods with these attributes to indicate whether the method is a setup method or teardown method. Then your tests should become cleaner and smaller as the ...


4

The big problem with databases and (unit-)tests is that databases are so darn good at persisting stuff. The usual solution is to not use an actual database in your unit-tests, but instead mock the database or use an in-memory database that can easily be wiped completely in-between tests. Only when testing the code that directly interacts with the database, ...


2

Component packages As for the component packages - this approach is usually called vertical folder (directory/package) structure and is common for larger projects. Structure of component Naming conventions are a little bit untraditional: Interfaces prefixed with capital I - this is C# convention, not Java one. In Java, interface is named without I - in ...


2

Working on a C# Server with SQL Server and PetaPoco, this is the approach we took to clean-up data in Unit Tests. A typical unit test would have Setup and Teardown as follows: [TestFixture] internal class PlatformDataObjectTests { private IDatabaseConfiguration _dbConfig; private Database _pocoDatabase; private PlatformDataObject _platformDto; ...


2

In this case, it doesn't look like it makes sense - the calculation is simple, quick and easily made in application code (or even in SQL). Adding the column means the storage for it is required, IO costs go up etc... Which is one cost/benefit analysis you need to make here. If the calculation were something highly CPU intensive, denormalizing as you ...


1

Ratio is a derived column that can be calculated. Store the value in database only for performance reasons. If your queries are slow. Otherwise do not store the derived column in the database. If you are not going to store the value in the database, which seems the most reasonable in your case, I recommend the following two options: 1. If the calculation ...


1

To my mind it isn't really data that needs to be stored. If you did store it of course, there is the complication that the ratio would need to be re-calculated should any of the underlying values change. Whatever way you do this will be messy - be it with stored procedures or triggers etc. You don't say how this fits into the system overall but you could ...


1

It depends. A bit of redundancy is allowed if comes with measured performance benefits. And this is if and only if you really need that performance boost, aka if it's a bottleneck in your application. So is it really that difficult to compute the ratio in your code? In your specific example I don't feel like the additional redundancy is justifiable. In my ...


1

I would argue that, in the case of AngularJS, utilizing callbacks is a code smell. I say this for the pure simple fact that AngularJS includes the notion of promises that you can leverage for the same use-case, and in fact look extremely similar in practice to the code you have already developed. Consider your test method: var testMethod = function() { ...


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


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


1

Use numeric status values where the higher value represents the higher state. Add that to your index in descending order. Then pull back the result ordered by time stamp and the status in descending order. This way the entry with the farthest progression is always returned.


1

A better approach would be two keep two tables, current and history. The current table would always be the latest update. The other table would be a history table, which would always be just inserts and reads. If you want to get the latest record, query the current table. If your not allowing any dirty reads it will always be the latest record. If you ...


1

Uncle Bob somehow hinted that programming is a very young discipline that doesn't yet have a stable body of laws or rules recognized by goverments (or was it Frederick Brooks?). I'm not making a verbatin citation here. You cannot revoke anyone the permit to program due to malpractice. Programming lacks a body of laws and rules than are legally enforced by ...


1

Here's my 5 cents of what I haven't seen others mention. When passing around variables you do not want to be passing by value, unless you really need to, to avoid extra constructions and destructions and copies. So unless you really must pass by value, using references everywhere, even if you do not mean to change the passed value is a significant ...



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