To address only the "goto fail" example the author uses, I don't see how the proposed Eiffel solutions are conceptually any different than always using brackets in your C/C++ constructs. Brackets are the mathematical notation for a set, and having a set of instructions inside them makes perfect sense even if the set only has a single element.
Since
if(condition){ instruction; }
instead of
if(condition) instruction;
is already considered good practice, couldn't it also be enforced via compiler pragma?
This is one of my most loathed developments in "best practices" lately. I see it everywhere and it just adds noise, since it doesn't change the functionality of the code. It's like adding a comment on every flow control statement. A concrete example is try/catch, which forces the user to add superfluous curly brackets.
In fairness, I have hit the "goto" style of bug he talks about in switch commands, when I forgot to add a break statement. But I can't remember a single time in my programming career when I added a line to an if/for/while and broke something.
I think people are wasting their energies on subjective topics like telling people to use spaces instead of tabs, or putting { on the same line as the flow control statement, or even telling people how much whitespace to use between () and where.
What we really need is a standardized formatter for any language that works like Google's Go Format. Programmers should not be spending time refactoring code just for looks. If anyone knows of a utility that does this and is easily configurable for personal taste, I would sure appreciate it. Being able to convert /* */ comments to // and back again would be a plus.
Formatters are usually language-specific, and there are formatters for most popular languages. See eg. clang-format [1] for C/C++, your IDE's reformat command for Java [2][3], PythonTidy [4] or AutoPep8 [5] for Python, or jsbeautifier [6], JSPretty [7], or Aptana [8] for JS.
> Brackets are the mathematical notation for a set, and having a set of instructions inside them makes perfect sense even if the set only has a single element.
The thing inside brackets in an if statement is a list of instructions, not a set, so there's no real reason that brackets use in mathematical set notation makes them natural for this use.
Yeah. Especially since those brackets are completely unrelated to set theory. An instruction can appear twice in a list of instructions, but not in a set. Also sets are unordered. The reason for the curly bracket choice was that most keyboards had a key for that back then.
A "list of instructions" is simply a "set of instructions" with an order. I was making a conceptual point, not a mathematical one. If you want to be pedantic, the instructions inside the brackets ultimately get converted to opcodes and their numeric arguments, which do form a set.
> A "list of instructions" is simply a "set of instructions" with an order.
No, its not, since an element can be repeated in a list but not in a set. To represent a list of instructions as a set it needs to be something like a set of (position, instruction) pairs -- like lines of code in old-style BASIC, with mandatory line numbers.
> If you want to be pedantic, the instructions inside the brackets ultimately get converted to opcodes and their numeric arguments, which do form a set.
No, they still don't. The "opcodes and arguments" are just instructions in a different language, and are still a list; you can have the same combination of opcode and arguments more than once, and the order still matters.
(If you include the offset in memory at which each instruction will be loaded along with the opcode and arguments making it up, then you'd have position-instruction pairs, and you could represent it as a set. But that's not what you are writing, and the fact that there is an equivalent set representation for something you are writing as a list doesn't make set delimiters natural delimiters for the thing written as a list.)
Doesn't that depend on what you consider your condition?
createSomething=function that creates something and returns true if correctly created and false otherwise
if(createSomething());
did that do nothing?
edit: perhaps nothing useful since we can't know the state returned by createSomething.
> Brackets are the mathematical notation for a set, and having a set of instructions inside them makes perfect sense even if the set only has a single element.
Then you consider that sets are unordered, and then the analogy doesn't make any sense any longer since the order matters for instructions.
Personally I think brackets are so important in C-like languages because they're such a pain for me to write on my keyboard.
Since
instead of is already considered good practice, couldn't it also be enforced via compiler pragma?