5 ms·

> The introduction of braces in the code was a trigger for a number of religious wars, and it made us, developers, focus on the design of the language instead o

> The introduction of braces in the code was a trigger for a number of religious wars, and it made us, developers, focus on the design of the language instead of focusing on the most important thing in our work - solving real problems. How can you correctly solve problems without being able to look at your code and reason, instantly, about what is grouped together. Let alone tracing through your code but just seeing what statements are grouped with what. One such suggestion, as provided by the author, is whitespace. I can't tell you how bad of an idea this is. Just from a teaching perspective. I help tutor for CS100 at my university and a large part of the errors I have to deal with are whitespace errors. People don't understand where a block starts and ends. It's less key strokes but that doesn't mean it's easier or better. > Languages like Java and C# made it to the almost ridiculous point where not only we have to be very explicit about every aspect of our code, but also made us split this code into an endless amount of files I see no issue with splitting up a problem into multiple parts that, if sufficiently different, could be hidden from each other. In the end, I don't think a language can be (un)productive. A language is the means for expressing a solution. Your job as a programmer is to conceive a solution to a problem and pick a language that will best let you express that problem. Some times functional languages are better at this, some times other languages are better. The thing we should be arguing about is what is best expressed in which language.

hockeybias 10y ago
Agreed. Threw up a little in my mouth regarding whitespace...
6DM 10y ago
I started a project out using jade in nodejs, after a while I had a page with enough elements/nesting going on that I was having a hard time keeping track of what was grouped where. Particularly when taking some work a designer did, making it jade compliant, then pasting in. Aside from a short "if" statement, I now no longer think it's sexy to abandon ending notation whether it be braces, elements, etc.
- gravypod 10y ago
  I'd suggest you not leave if statements un-braced. I remember a study where they found the most common bug in most experienced open source developers was leaving out the braced initially, going back to make a change, and having that change introduce a bug. Basically they had if (x) then() and went back and did if (x) new_call() then() and caused an error that happened silently. This is something you definitely want to avoid and I personally don't trust myself, after a no-sleep code fixing bender, to remember to add {} around something if I'm editing an if. I'd probably forget. Again, I'd say shorter does not mean better.
  - deleted 10y ago
    [deleted]
  - papaf 10y ago
    One way round this is to put single statement ifs on a single line: if (x) then(); If you add another statement to the if, its obvious from the indent that you need to use braces.
    - petre 10y ago
      Yup, I always do this when writing JavaScript or other languages that allow prefix single statements with or without braces. Otherwise I use braces if the statement is too long to fit in the editor w/o forcing you to scroll. Perl only allows postfixed single statements w/o braces, so you're safe: say "yes" if $condition; if ($condition) { say "yes"; $affirmative++; }
  - gpderetta 10y ago
    7: warning: this 'if' clause does not guard... [-Wmisleading-indentation] if (x) ^~ 9 : note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' then(); ^~~~
    - gravypod 10y ago
emodendroket 10y ago
> I see no issue with splitting up a problem into multiple parts that, if sufficiently different, could be hidden from each other. I'd go so far as to say breaking a problem up into black boxes that solve smaller parts of the problem is one of the most basic skills in programming.
dllthomas 10y ago
> Just from a teaching perspective. I help tutor for CS100 at my university and a large part of the errors I have to deal with are whitespace errors. People don't understand where a block starts and ends. On the flip side, when I was in school and a peer asked me to look over their code, it was usually an unindented mess and they still very much had no idea "where a block starts and ends" despite the braces. When Python was introduced, I was hopeful that a technical demand that indentation be done properly might actually help, pedagogically. On reflection, imposing this at linting with a brace-based would probably be better still, as the error messages could be substantially better targeted.

hockeybias 10y ago

Agreed. Threw up a little in my mouth regarding whitespace...

6DM 10y ago

I started a project out using jade in nodejs, after a while I had a page with enough elements/nesting going on that I was having a hard time keeping track of what was grouped where. Particularly when taking some work a designer did, making it jade compliant, then pasting in. Aside from a short "if" statement, I now no longer think it's sexy to abandon ending notation whether it be braces, elements, etc.

gravypod 10y ago
I'd suggest you not leave if statements un-braced. I remember a study where they found the most common bug in most experienced open source developers was leaving out the braced initially, going back to make a change, and having that change introduce a bug. Basically they had if (x) then() and went back and did if (x) new_call() then() and caused an error that happened silently. This is something you definitely want to avoid and I personally don't trust myself, after a no-sleep code fixing bender, to remember to add {} around something if I'm editing an if. I'd probably forget. Again, I'd say shorter does not mean better.
- deleted 10y ago
  [deleted]
- papaf 10y ago
  One way round this is to put single statement ifs on a single line: if (x) then(); If you add another statement to the if, its obvious from the indent that you need to use braces.
  - petre 10y ago
    Yup, I always do this when writing JavaScript or other languages that allow prefix single statements with or without braces. Otherwise I use braces if the statement is too long to fit in the editor w/o forcing you to scroll. Perl only allows postfixed single statements w/o braces, so you're safe: say "yes" if $condition; if ($condition) { say "yes"; $affirmative++; }
- gpderetta 10y ago
  7: warning: this 'if' clause does not guard... [-Wmisleading-indentation] if (x) ^~ 9 : note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' then(); ^~~~
  - gravypod 10y ago

emodendroket 10y ago

> I see no issue with splitting up a problem into multiple parts that, if sufficiently different, could be hidden from each other. I'd go so far as to say breaking a problem up into black boxes that solve smaller parts of the problem is one of the most basic skills in programming.

dllthomas 10y ago

> Just from a teaching perspective. I help tutor for CS100 at my university and a large part of the errors I have to deal with are whitespace errors. People don't understand where a block starts and ends. On the flip side, when I was in school and a peer asked me to look over their code, it was usually an unindented mess and they still very much had no idea "where a block starts and ends" despite the braces. When Python was introduced, I was hopeful that a technical demand that indentation be done properly might actually help, pedagogically. On reflection, imposing this at linting with a brace-based would probably be better still, as the error messages could be substantially better targeted.