Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I realize this is somewhat subjective, but I can't find a good case for one or the other :

it "should do something"
it "does something"

Proponents of the should style mention that it forces you to actually question what it is you are trying to achieve, while detractors find it just redundant.

Is there a consensus on this, or is it purely a matter of style ?

share|improve this question

4 Answers 4

up vote 4 down vote accepted

Welcome to Legal English.

Using "should" == "shall" == contractual obligation. It's a legalism. It doesn't lead to "questioning". It marks the sentence as a formal contractual obligation.

Using "would" == "will" == nice idea. It marks the sentence as an optional feature.

Questioning is part of facilitation, organization, helping, building trust. Not a consquence of word choice.

Using a bare verb without the modifier makes the sentence slightly harder to highlight as a formal requirement. And in the case of super-complex verbs, it can get a little dicey to figure out how to conjugate it.

Easy -- verbs like "to notify" or "to create".

  • The system notifies via email. (The verb "to notify" is conjugated "notifies" for "the system"--whatever that is.)

  • The system shall notify via email. ("to notify" becomes "shall notify" -- no conjugation. Very simple.)

Hard -- verb phrases like "to log in" or domain-specific verb phrases like "to extract, cleanse, transform, deduplicate and load" or a noun like "prospect" which has been verbed. The longer phrase which has several verbs buried in it is hard to conjugate: conjugate each verb? Or try to conjugate the long phrase as if it was a single word? Since any noun can be verbed in English, it's hard to know how to conjugate those made-up verbs.

  • The system extract, cleanse, transform, deduplicate and loads when the user clicks enter. (English trivially verbs any noun phrase.) Or is it extracts, cleanses, transforms, deduplicates and loads?

  • The system should extract, cleanse, transform, deduplicate and load when the user clicks enter. (The hideous phrase is left intact, no mystery about the verb conjugation.)

["What?" you say, "any noun can be verbed in English?". Yes. Any noun. I'm going to stonewall on that. I've often stonewalled on that. Even the specifications should stonewall on that.]

share|improve this answer
    
Accepted as this answer made me realize how conjugation could make matching steps harder in some cases. –  julien Feb 10 '11 at 7:23
2  
You say that using "should" doesn't lead to "questioning"; my experience is that it does, especially with people new to testing / TDD. It also has the effect of differentiating outcomes from context and events. "And the order arrives at the warehouse" doesn't tell me if I'm causing the order to arrive by pressing a button, or if it should happen automatically, whereas "And the order should arrive at the warehouse" tells me that this is something I should be checking. BDD is about conversational, not legal, English (or natural language of choice). –  Lunivore Mar 11 '11 at 18:21
1  
It's the idea that you use "should" in a legal, non-questioning way that I don't find useful. Kind of the opposite of the deliberate discovery mindset which BDD started with. I spend my life trying to help people who started with "spec" and then feel like they can't question it. –  Lunivore Mar 14 '11 at 15:48
1  
If you were to edit your answer so that it included something like, "Some people like 'should' because it leads to questioning" instead of what it currently says, which is "it doesn't lead to questioning", I would be very happy. The questioning aspect of BDD is one of the most important, for me, and the way you've phrased this eliminates this aspect rather than providing additional context. Thank you for this conversation, regardless of whether you edit the answer or not; I really appreciate the respectful dialogue. –  Lunivore Mar 15 '11 at 8:02
3  
The IETF Standard for writing RFCs specifically states that 'MUST' and 'SHALL' are 'REQUIRED', 'SHOULD' is 'RECOMMENDED', and 'MAY' is 'OPTIONAL'. –  oosterwal Mar 15 '11 at 21:39

Purely a matter of stylistic preference. It boils down to asking, do you/your clients prefer to think about the system in present or future tense?

Qualifiers like "should" or "will" implies future tense, but this is soft and reads well enough when thinking in present tense. Lack of a qualifier definitely indicates present tense (i.e. right this moment).

I prefer using a qualifier because it reads passably well in both cases, whereas lack of qualifier reads a bit strangely during development when everything is future tense.

In any case, if you decide to use a qualifier I strongly recommend using "must" instead of "should". "Should" can be interpreted as being optional (despite S.Lott's assertion to the contrary), but "must" completely removes any ambiguity - must clearly means "not optional".


And because I can't yet comment (karma constraints), this is a response to S.Lott about Should/Shall vs. Would/Will: there's a lot of ambiguity about shall and will, even in legal contract writing. See this article for an explanation.

share|improve this answer

In my opinion, you should always use 'should'.

Reasoning - with BDD, when you're writing the test, the software doesn't yet do what you want it to do, so saying it "does something" is false. It "should do something", and the tests will pass as long as it continues to do that something.

share|improve this answer
    
"Doesn't yet exist" seems to be more reason to use present tense instead of "should". BDD is for acceptance testing and if a system does not yet do something then it ought to fail immediately. There seems to be a divide among BDDers as far as using "should" or not. –  Brenden Jun 3 at 16:15

I thought I might offer a little food for thought:

There's a page over at behaviour-driven.org titled "[GettingTheWordsRight]"(http://behaviour-driven.org/GettingTheWordsRight) that came to mind as I read the OP's question. In short, it mentions that the words that we use to describe things influences the way in which we (and others) think about those things. This isn't just a simple question of being petty about semantics either, as certain words carry with them nuances that affect how we interpret the meaning of a phrase at both an intellectual and an emotional level. Our language is rich with descriptive words and phrases so it seems reasonable to use words that will clearly convey the intention of the elements that we wish to describe in code.

In the case of BDD, I'm personally who almost always uses the word should when naming tests, because its usage implies that while the intention is for a test to provide a certain result, other unexpected consequences may arise which will need to be dealt with if a test result is to be considered valid. You could perhaps use the words expect or must similarly, however these words imply a more imperative viewpoint such that the name of the test could be mistaken to mean "there is nothing wrong with the test, assume the implementation is messed up", whereas *should" implies that the test is likely to be correct, yet may need to be checked again for error if the test results don't seem to add up. I like this, because it influences your thinking such that you are encouraged to keep an open mind as you code, which is very important when you wish to avoid getting stuck as you attempt to debug your code and find yourself looking in the wrong place for errors because of an assumption.

I have however seen the near 'religious' application of the word should fail when it has been enforced as a prefix for test names, as it has forced the programmers involved to go through certain mental and linguistical gymnastics in order to provide a test name that was meaningful, and in such cases it has meant that the intention to get the words right does not meet its expectations, and the tests themselves become difficult to decipher as a result. When this sort of situation crops up, I would usually use the word should at any place within the test method name, to ensure the name conveys its method simply and clearly. I would certainly not however enforce a particular word usage if other words were equally appropriate within a given context. The trick however is to choose words that leave no room for argument about what something represents in code, and that provoke you into thinking about the things that your code is supposed to do without relying on mere implication.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.