"Otherwise" after "where"

Here is a passage in a technical document I'm working on:

Simple vs. associative arrays

• Where you need key-value pairs, use associative arrays.
• Otherwise, use the simple ones.

As I felt, there was something wrong with "where + otherwise" pair, and as FumbleFingers confirmed in the first comment, this feeling was correct: this pair doesn't really work well.

One way to workaround this issue is to use "if" instead of "where". Though it will fix the passage posted above, I cannot say that I really can use this solution. This is because that document has other similar passages that uses "where you need", "where possible", or "where necessary", and I want to use the same word ("where" or "if") for all of them. Unfortunately, some of them (maybe I'm wrong!) don't accept "if". For example:

Case-sensitive equality operator

• With regular strings, use it only where necessary.
• With the empty string and numbers, use it on every occasion.

"On every occasion" points to a location or maybe time, and thus using "if + on every location" looks somewhat asymmetric to me.

And another reason that I don't want to replace all my "where"-s with "if"-s is that "if" creates some ambiguity. I would reserve it for passages like this one:

• If you think you are really skilled, feel free to use the ternary operator.
• If you don't think so, don't use it.

How to rephrase the first passage without replacing "where" to something different?

Solution 1:

As a developer (currently not visible on SO as yet - though that's where I started reading along on Stackexchange back then), I think

there is perfectly nothing wrong here with "where... otherwise".

These are well-established ways of expressing circumstance in a problem (or more exactly, properties) akin to mathematics where "where..." is what to use to describe properties of an element in a problem and "... otherwise" may be used to denote "all other cases" after some have been described.

As already pointed out in great detail in this answer, there is obviously nothing wrong with this grammatically either.

The same would hold from a purely pragmatical point of view - such as to make oneself understood in exactly the way that would be on point and expected for the reader to get an unambiguous grasp of what they are being taught. In development (and mathematics), it's perfectly customary to use exactly this wording.

Although I'll add that my feeling with where you need is slightly off the track beaten by mathematic usage as that would be more strictly describing properties of parts of a problem rather than conclusions such as an implementation detail commanded by an ongoing design decision. But that seems to me a very minor difference in this case and does not command a change at any rate.

So the wording already present would be as close to perfect as it can get unless a completely different avenue were to be taken to describe the facts (and what would that be?).

The wording as is is perfectly correct in the field of software development - to go deeper, which I don't think is necessary, a look at vocational language could provide additional insight.

As an extra precaution, though rather not language-wise, the passage in question might stand a check on Stackoverflow or Software Engineering, because there is something that feels slightly off (although Javascript is not exactly one of my first batch of languages) about the second line and I'm not perfectly sure of what it is. That one, though, could be just oversensitive gut feeling on the language tier on my part anyway, then leaving the factual point unchallenged.

To go still deeper, a check for slight variation in register could be made, but again, of course depending on what is being aimed for, I wouldn't overdo it already having a perfectly suitable expression.

As for uniformity as a goal with respect to the other examples, experience from reading lengthy formal documents (where uniformity in clauses is sometimes required) shows that it can contribute rather negatively to the ability of the reader to keep their attention focused on their read. So it seems preferable to rather avoid perfect uniformity where not required because of sound reasons.

Stereotypical expression in a formal description of e.g. requirements may help the reader as they would be reading from a different angle - scarcely looking at the sterotyped parts of the text at all - as they are not learning but instead going through a (semantically) rather checklist type of document.

The ifs in the last example passage are perfect, too - that's a different kind of differentiation, so they are perfectly where they belong.

Solution 2:

I frankly don't understand why otherwise cannot be used along with where.

The online Oxford Dictionary defines otherwise as:

In circumstances different from those present or considered; or else.

Since where in the OP's examples can be easily construed as denoting circumstances (as opposed to places), the use of otherwise along with where is not unnatural at all.

Replacing where with when would be unnecessary unless you want to emphasize the temporal nature of the circumstances, which isn't clear from the examples.

Solution 3:

The problem with where is that the customary alternative to where ... is elsewhere .... So if you want to keep where, you're left with two choices:

1. Use elsewhere, which doesn't work quite as well as otherwise for this metaphorical use of where.
2. Use otherwise, which isn't that bad an alternative; it may sound slightly wrong to some ears, but judging from the answers and comments, most people would skip right over it.

I think both of these choices are perfectly reasonable—use whichever one sounds best to you.

Solution 4:

I probably exclude myself from the bounty by saying that the question is based upon a misunderstanding and thus that the problem does not exist.

Where you need key-value pairs, use associative arrays. ' / Otherwise, use the simple ones.

You: As I felt, there was something wrong with "where + otherwise" pair, and as FumbleFingers confirmed in the first comment, this feeling was correct: this pair doesn't really work well.

Fumble Fingers: I think it would be much better to use if instead of where. Then the possible "semantic clash" between (metaphoric locational) where and (metaphoric methodological) otherwise wouldn't arise anyway.

I can't agree. There is no clash. "Otherwise" is not restricted to a methodological meaning; it is also locative. = in other circumstances. (The preposition "in" is locative = within; inside.)

Circumstances are a location and that is why we can say "Where you need key-value pairs, use associative arrays. ' / Otherwise/in other circumstances, use the simple ones.

OED

Otherwise

3. In another case; in other circumstances;

1726 J. Swift Gulliver II. iii. x. 143 By this Defect they are deprived of the only Entertainment whereof they might otherwise be capable.

1952 B. Pym Excellent Women ii. 14 Women did not tend to fuss over him as they might otherwise have done. 1988 in R. Dinnage One to One 145 I'm very glad someone gave me the push to do that. I might not have done it otherwise.

Thus, the pairing works perfectly, and "where otherwise" is very common (although a little formal). See also Google Ngram at “where otherwise”

Solution 5:

As has already been pointed out on this page, there is nothing really wrong with the where/otherwise pairing, so one doesn't have to change it. But if one is bothered by it, and really wants to avoid otherwise (while keeping where), it may be helpful to note that 'Where you need key-value pairs . . .' means the same as 'in the cases in which you need key-value pairs . . .'. This can lead one to:

• Where you need key-value pairs, use associative arrays.
• In all other cases, use the simple ones.