New answers tagged

-1

Once you remove dynamic dispatch from the mix, the answer is that there is no reason, other than convention, that we do it that way. In English, we read/write from left to right. Why? No reason other than convention. I get the impression that you are being much too quick in discarding convention. Conventional code is easier to write, easer to read and ...


1

One big reason is polymorphism (not inheritance, which is just one form of polymorphism). Consider the following example: interface Payable { ... double calculatePay(); ... } public class HourlyEmployee implements Payable { ... public double calculatePay() { return hourlyRate * timeCards.totalHoursWorked(); } ... } public class ...


3

Don't underestimate the power of convention. If everybody does things the same way, it makes big programmes more maintainable. Your example StaticLib.Something(...some parameters...); only looks simpler because you've glossed over the details. You haven't actually stated where the MyStruct data is initialised, nor passed it into the Something function. ...


-2

I think it might be Java related, where everything has to be in a class (even when, as you point out, its not ever in an instance of a class). C++ allows normal functions, but also maintains the static keyword that used to constrain a variable or function's scope to the containing file. C++ kept this meaning but modified the scope to the containing class, ...


2

Debug code has been included in programs for practically as long as they have been written. The elephant in the room however is that your testing cycles are not against the version that will eventually ship . While finding some issues early might outweigh the cost of finding hidden bugs later, it is certainly a risk to consider. You also need to be careful ...


0

Depending on the design of the application your approach might be necessary. I find that the best way to debug UI applications is to be able to initialise it with a state from the beginning (for example from a JSON dictionary). Then the only debugging entry is the initial state. This is fairly easy if you develop web based applications and very easy if ...


6

This is not so much an indicator of bad practices as a strict test of your deployment process. Obviously it is very bad if debugging controls, content, backdoors etc. get into production environments. But if they help you achieve the same business goal faster, they save the company real money. Therefore the crucial factor is to ensure that they cannot get ...


3

What are some reasons you may choose a worse runtime algorithm? By far the most common reason is that the "worse" algorithm is a lot simpler, or is the first solution I think of, and getting mathematically optimal performance just doesn't matter in the part of the code I'm currently working on. Which is most parts of the code. Another common reason is ...


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


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

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


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


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


6

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


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


0

A unit test should be able to use any code or logic that itself is properly tested. A unit test should have minimal logic in it. It should be straight forward as to its test and that one can look at it and reason about it. Reimplementing an equals method violates DRY. In doing so, it introduces the possibility of having equals diverge and a bug slip in to ...


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


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


0

Cool your learning c, you just discovered one of c little tongue twisters. You are not doing pointer arithmetic on an array, but an array of pointers. Doing pointer arithmetic on arrays is not possible. An array decays to a pointer but is not a pointer type it self. What you my have (see comment by cmaster) is int *array[]; //This is a array to pointers ...


0

Your colleague is right. Order by the primary key. The primary key is not devoid of meaning. It identifies each row in the table. It is numeric, which implies the order in which records were created. It doesn't fit perfectly into the terminology of your business domain, but don't overlook the simple and obvious solution for ideological reasons, especially ...


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


0

It sounds like an event sourcing approach would be helpful here http://martinfowler.com/eaaDev/EventSourcing.html essentially, each time you update the object, you load it, add the event to the history and save everything. When you save the object, you check to see that nothing else has updated the history in the meantime. If they have, you rebuild the ...



Top 50 recent answers are included