-1

Formatting with Indentations, White spaces, and New Lines obviously fit into the coding style category.

if (a == b) {
    foo();
}

// vs

if (a == b)
{
    foo();
}

On the other hand, something that changes the run time of a program is no longer a matter of coding style, and becomes a matter of algorithm.

for (var i = 0; i < a.length; i++) {
    // Remove first element of the array.
    a.shift();
}

// vs

for (var i = 0; i < a.length; i++) {
    // Remove last element of the array.
    a.pop();
}

However, at what point does a matter of coding style turn into a matter of algorithm?

In other words, when comparing two possible methods to write the same program, when can we objectively determine whether the choice between the two methods is a preference in coding style or a difference in algorithm?

Is comparing to true a matter of coding style or algorithm?

if (a == true) {
    // a is true.
}

// vs

if (a) {
    // a is true.
}

Is returning true a matter of coding style or algorithm?

function isA(b) {
    return this.a == b;
}

// vs

function isA(b) {
    if (this.a == b) {
        return true;
    }
    return false;
}

What about merging conditions into one if statement?

if (a > 0) {
    return foo();
}

if (b == 0) {
    return foo();
}

// vs

if (a > 0 || b == 0) {
    return foo();
}

Loop conditions?

// Loop 10 times.
for (var i = 0; i < 10; i++);

// vs

// Loop 10 times.
for (var i = 1; i <= 10; i++);

Nested if statements?

function foobar() {
    if (a) {
        return foo();
    }

    if (b) {
        return bar();
    }

    return barfoo();
}

// vs

function foobar() {
    if (a) {
        return foo();
    } else {
        if (b) {
            return bar();
        } else {
            return barfoo();
        }
    }
}

These examples don't exactly change the run time of a program, yet isn't exactly just indentations, white spaces, or new line changes either. They are also typically not mentioned in coding style guides for most languages.

Given these examples above and other similar examples, is the difference a matter coding style or algorithm? Or is there a completely different term for it?

For example, if I am someone who uses for (var i = 0; i < 10; i++), do I simply have a different preference for coding style compared to someone who uses for (var i = 1; i <= 10; i++)? Or is there something more to it besides just coding style? At what point is it no longer just coding style and start becoming part of the algorithm?

closed as unclear what you're asking by gnat, user40980, durron597, user22815, GlenH7 Oct 26 '15 at 21:52

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Possible duplicate of Clean readable code vs fast hard to read code. When to cross the line? – gnat Oct 24 '15 at 21:16
  • I think there is some difference between this question and Clean readable code vs fast hard to read code. When to cross the line?. In my question, the examples I've given are arguably equally clean, readable, and fast. However, I am asking that at what point do equally clean, readable, and fast code no longer become a preference of coding style and start becoming more than that. (if ever) – Zsw Oct 24 '15 at 21:33
  • 1
    Besides coding style, there is also idiomatic usage of a language. This essentially means what is customary among users of a particular language (and sometimes even a sub-group of users). – Bart van Ingen Schenau Oct 26 '15 at 10:53
4

Short answer:

Are the two versions of code capable of producing different outcomes when executed? If so, they are probably different algorithms.

The kinds of outcomes we're concerned with:

  • Results of the execution. For example, shift and pop modifies the array in different ways, so the content of the array is different. Any other code that has access to the array needs to be aware of how it was intended to be modified.

  • Differences in qualities, or "non-functional requirements". For example, if the time taken by the operation "grows linearly (proportional) to the current size of the array", its performance is different from another which "grows quadratically to (proportional to the square of) the current size of the array", then it is likely that the two code implements two different algorithms.

  • There are many other outcomes we might be concerned with, depending on the nature of the software projects.


Longer answer:

To be able to reason about whether some code changes will result in a change in the algorithm, one needs to:

  • Reason logically. Article: boolean algebra.
  • Understand the rules of the language very well.
  • Have a simplified mental model of how the code would be executed, step-by-step, by a computer (or computer program / virtual machine).
  • Understand possible ways in which the compiler or the execution program may diverge from your simplified mental model.

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