I can not work with dummy data, as the main functionality I am testing is the connection to a black box remote server, which only gets the data from the first submodule.
This is the key part for me. You can talk about "unit tests" and them "running independently of each other", but they all sound like they are reliant on this remote server and reliant on ...
As NickWilliams has already said: the concept the OP describes is called idempotent (noun Idempotency). It is indeed common practice, especially in high-level APIs.
BUT: Rename the function.
Instead of startHttpServer call it makeSureHttpServerIsRunning or ensureHttpServerIsRunning.
When a function is called startHttpServer, readers expect it to start a ...
After many edits, this answer has become a monster in length. I apologize in advance.
First of all, eval() isn't always bad, and can bring benefit in performance when used in lazy-evaluation, for example. Lazy-evaluation is similar to lazy-loading, but you essentially store your code within strings, and then use eval or new Function to evaluate the code. If ...
"The Mythical Man-Month" came out the year I started college and was, to use the current vernacular, UUUGE! :-) What you need to understand is the difference in how software was developed THEN vs. NOW. Back In The Day (tm) pretty much all coding was done on paper first, was then keypunched onto (you guessed it) punched cards, then was read in, compiled, ...
There are some aspects of that concept that are sometimes implemented today, there are other aspects that are avoided.
Keeping teams small is one of the basic features of Agile Methods, but is also practiced outside of Agile.
Cross-functional teams are also a staple of Agile, but common outside of Agile as well.
The role of the Program Clerk is largely ...
When reviewing code, I apply the following rules:
Always use const for function parameters passed by reference where the
function does not modify (or free) the data pointed to.
int find(const int *data, size_t size, int value);
Always use const for constants that might otherwise be defined using a #define or an enum. The compiler can locate the data in ...
When in doubt, ask someone else.
Your example function has a very similar one in Python: itertools.combinations. Let's see how it works:
>>> import itertools
>>> input = [1, 2, 3, 4, 5]
>>> list(itertools.combinations(input, 2))
[(1, 2), (1, 3), (1, 4), (1, 5), (2, 3), (2, 4), (2, 5), (3, 4), (3, 5), (4, 5)]
Gave +1 to @JesperE, and like to add something:
is it violating some programming principles
Yes, "convention over configuration" violates the principle "explicit is better than implicit" (have a look, for example, at "Zen-Of-Python").
On the other hand, the opposite "configuration over convention" tends to violate "Simple is better than complex", and ...
It's not an antipattern, it's a bad practice.
The difference between an antipattern and a mere bad practice is here: anti-pattern definition.
The new workplace style you show is a bad practice, vestigial or pre-OOP times, according to Uncle Bob's Clean Code.
Arguments are most naturally interpreted as inputs to a function.
Anything that forces you to check ...
In layman's terms:
If there is an error, you should raise an exception. That may involve doing things in steps instead of in a single chained call in order to know exactly where the error happened.
If there is no error but the resulting set is empty, don't raise an exception, return the empty set. An empty set is a valid set.
If a language inherently supports exceptions, then it is preferred to throw exceptions and the clients can catch the exception if they do not want it to result in a failure. In fact, the clients of your code expect exceptions and will run into many bugs because they will not be checking the return values.
There are quite a few advantages to using exceptions ...
Allow me to disagree with Michal Charemza answer.
Although his answer is theoretically correct, it is not very practical for the real world.
I am saying that because I used to think like that and tried to enforce it on a large real world app that myself and my team are building and it just became too troublesome.
The analogy to the HTML language is not ...
I agree with Ewan's answer but want to add a specific reasoning.
You are dealing with mathematical operations, so it might be a good advice to stick with the same mathematical definitions. From a mathematical standpoint the number of r-sets of an n-set (i.e. nCr) is well defined for all r > n >= 0. It is zero. Therefore returning an empty set would be the ...
I don't consider "an application should be fully explained by its own code" a fundamental programming principle. There are lots and lots of things which are not explained by just looking at the code of an application. Apart from knowing the basic things of the programming language itself (syntax and semantics), you need to know the conventions. If an ...
Provide the strings. Numbers are meaningless. You don't use them in your own code, right (you're wrapping enum values around, that are basically strings) - why punish the user with having to use these numbers?
The only pro if you do expose the numbers - easier for you to parse these. But hey, who cares about you. Take care of the API clients.
If you ...
The ideal is that the application is a black box. In testing you feed it a variety of inputs and observe the results.
In reality, there are tradeoffs. Some tests are really expensive to write. Some tests have low value. No testing is ever 100% so it's also a business decision when it's "good enough". Every time something is mocked or special conditions are ...
Prior to generics in .NET, it was common practice to create 'typed' collections so you would have class CarCollection etc for every type you needed to group. In .NET 2.0 with the introduction of Generics, a new class List<T> was introduced which saves you having to create CarCollection etc as you can create List<Car>.
Most of the time, you will ...
I work with an application that uses bitmasks to store user role assignments. It's a pain in the butt. If this makes me biased, guilty as charged.
If you're already using a relational database, it is an anti-pattern that violates most relational theory and all the normalization rules. When you build your own data storage, it may not be such a bad idea.
The helper function is a private implementation detail. Putting it at the same scope is akin to making a class' private functions public.
If it turns out to be of more general use, it's ...
Have you considered localization?
It may look simple to write something like:
var text = (count > 0) ? "items" : "item"
But it's nowhere near that simple when you have to work in multiple languages. Here's an example, just using Google Translate:
Language | Singular | Plural
Yes, it's a bad practice.
Generally, a unit test is intended to test a single unit of code (e.g. a single function based on a known state).
When you want to test a chain of events that might happen in the wild, you want a different test style, such as an integration test. This is even more true if you're depending on a third party service.
To unit test ...
Not really a design pattern but I would call your method idempotent. There term is usually used to refer to remote calls but the description seems the match what you are doing.
Idempotent Methods. Methods can also have the property of
"idempotence" in that (aside from error or expiration issues) the
side-effects of N > 0 identical requests is the ...
If you are on a team, do what they usually do. Otherwise just pick the one you like more. On the scale of important design choices this is probably somewhere near "which thumb should I use to hit the space bar?"
As someone who regularly dealt with updating production database for customers for our software upgrades, I tell you that the best way to minimize errors is to make updates as straightforward as possible.
If you can perform a change to all records rather than specific records, it is preferable.
In other words, if you're given a list of ids of records which ...
The problem isn't the local catch block, the problem is the log and rethrow. Either handle the exception or wrap it with a new exception that adds additional context and throw that. Otherwise you will run into several duplicate log entries for the same exception.
The idea here is to enhance the ability to debug your application.
Example #1: Handle it
A directive is best (as a rule-of-thumb) when it's short (code-wise), (potentially) re-usable, and has a limited a scope in terms of functionality. Making a directive that includes UI and depends on a service (that I assume handles connection to the backend), not only gives it 2 functional roles, namely:
Controlling the UI for display/entry of data for the ...
You have already named the relevant pros and cons:
Bit fields save space.
They store data in the record itself, so you don't need JOINs to find them. (But individual flag fields in the record would do the same.)
They are badly readable if you want to work productively with raw SQL output.
Deciding what to do requires more info:
Just how scarce is disk ...
I find a good way of determining whether to use an exception, is to imagine people being involved in the transaction.
Taking fetching the contents of a file as an example:
Please fetch me the contents of file, "doesn't exist.txt"
a. "Here's the contents: an empty collection of characters"
b. "Erm, there's a problem, that file doesn't exist. I don't know ...