• Vera (unregistered)

    It could also have been a case of "OK, this bit of code might be doing something weird, let's comment it out. Good thing my IDE lets me //-comment stuff easily. ...OK, works now, let's just restore the parts that I need again"

  • Ginssuart (unregistered)

    // Frist Secnod // FileNotFound

  • Ginssuart (unregistered) in reply to Ginssuart

    How to make a new Line?

  • John Melville (unregistered)

    The author wrote: because I've seen developers do exactly that.

    A more honest author would have written because I've done exactly that.

    Anyone who has never just hit closing brace, closing brace ... etc until the IDE said you were hasn't programmed very long ... and has never even heard of Lisp.

  • Scragar (unregistered) in reply to John Melville

    If you have good indenting or an IDE that tells you what braces match there is zero reason to ever do this.

    The only time this ever happens is when your indenting and IDE make identifying the matching braces unclear.

  • (nodebb) in reply to Scragar

    My boss learned to code in Pascal in the 90s so he doesn't like methods with more than one "return" and he also prefers 2-space indentation. That compounds to a lot of nested if-elses and the indentation lines in his IDE look so close to each other it's very hard to tell which is which.

    I light a candle and celebrate every year on the day I managed to convince him of switching the company standard from spaces to tabs so the rest of can use a more reasonable setting that doesn't make out eyes bleed.

  • (author) in reply to Scragar

    I will say, I've seen code so craptacular that it breaks the IDE's brace indenting, which you'd think should be impossible, yet…

    The IDE basically gives up on auto-indenting and things get all jacked up, and if you're already in a state where the code is that bad, there's really no hope of fixing it to get the IDE working properly again.

    // I haven't seen that for awhile, admittedly, which either I'm working on better code bases or IDEs have gotten better

  • (nodebb) in reply to John Melville

    Anyone who has never just hit closing brace, closing brace ... etc until the IDE said [...]

    Anyone who relies on an IDE has not been coding as long as I have. Character cell 80x24 monitors, all CLI, no command recall, and vi (not vim, thankyouverymuch) could barely match parens when checked manually. IDEs are a useful tool, not a replacement for your brain.

  • (nodebb)

    I've seen this when it goes along with a commented out if line, turning a conditional block into unconditional. Some people like to leave these comment lines in the code so that it's easier to see the evolution, rather than having to look at the version control diff.

  • (nodebb) in reply to AGlezB

    Wow, congratulations. I failed to convince the leader of the multi-team project my team joined of the same.

  • (nodebb)

    More than once I've wished for a language which requires 2-char braces, thus making it much easier to match them up ( assuming you're not one of those who type an opening "{" and thinks 'I'll get around to typing the "}" later' ) . Like

    function foo(x) {1 x=3 for j 1,10{2 y = x }2 }1 But yes I agree the IDE should pair them up, and if your lines are too long or the lambda has too many lines, you should refactor.

  • dusoft (unregistered) in reply to AGlezB

    Who cares about 2 space (tabs, spaces etc.) indentation. Every modern editor / IDE will automatically lint to whatever your preferences are. Next time somebody else opens that code it will get reindented on opening.

  • (nodebb)

    If that comment is in the middle of the file it's likely to be the knee brace of a{n old and obsolete} developer

  • guest (unregistered)

    We have. It also has the nicest implementation of lambdas and some wonderful other syntactic sugar. And then people complained that Visual Basic syntax was for babies, not real programmers, so we got C# instead.

  • Petter (unregistered) in reply to Barry Margolin

    Especially when it's a work-in-progress PR: Comment out a conditional, run some tests, restore it, back and forth…and then at the end of the day maybe you remember before merging to delete the commented header part but not the commented terminal brace. Should be caught in code review, but not IMO a clear signal of anything egregious.

  • AussieSusan (unregistered) in reply to John Melville

    RE Lisp - didn't some Lisp compilers get around the enumerable closing bracket problem by using ']' ???

  • (nodebb)

    it's likely to be the knee brace of a{n old and obsolete} developer

    And hopefully retired...like me.

  • (nodebb) in reply to AGlezB

    I ran into that problem with Uni assignments in the 1980s, I was used to C with break/return and had to grit my teeth every time I was forced by the language to write ghastly if/then/else chains with control percolating up and down the chain in difficult-to-follow ways. The real pain point was that I was using Turbo Pascal rather than Mac Pascal or whatever the required B&D environment was, but couldn't use any of its additional features because Mac Pascal didn't have them. I did get dinged a few times for doing things the non-B&D way because I didn't realise that I'd used a non-Mac-Pascal language feature.

  • (nodebb) in reply to AGlezB

    Wow, just wow. My first formal education in programming was also in Pascal around the same era. I don't understand how someone requires (extensive!) convincing from someone else that tabs are a good idea, let alone that they should be mandated.

  • Your Name (unregistered)

    How can anybody sane ever prefer tabs. Ask any text editor control developer what a fine thing tabs are.

    Also, 2 spaces is the god given default for indentation, exactly as (Turbo) Pascal showed.

  • Nick (unregistered) in reply to dusoft

    Who cares about 2 space (tabs, spaces etc.) indentation. Every modern editor / IDE will automatically lint to whatever your preferences are. Next time somebody else opens that code it will get reindented on opening.

    I do hope I never work on a project with you, if that’s your approach. With that strategy, every commit will consist of 1 line of meaningful change, and 499 lines of “but I want my white space this way” - which will make it almost impossible to use any standard tooling on the source control history to figure out when/why a change was made.

    The ONLY correct indentation strategy is “follow what’s used in the rest of the existing code in the project, or in other projects at this company”. If you’re starting from scratch, with no existing code at all, then you have free rein to make your own choice… in which case, almost any solution is fine, with the exception of “three spaces”, which is just cursed.

  • Tgape (unregistered) in reply to Remy Porter

    I will say, I've seen code so craptacular that it breaks the IDE's brace indenting, which you'd think should be impossible, yet…

    I'm not sure why, but it seems most of the IDEs I've used don't handle commented, escaped, or quoted braces well. Some of them will do one, some will do another, but I'm not aware of having found one that does brace matching and handles commented, escaped, and quoted braces well.

    What I would like it to do is to consider each of these to be a separate thing, so normal braces never match one that's quoted, escaped, or commented. Commented quoted escaped braces match each other, uncommented unquoted escaped braces match each other, uncommented quoted unescaped braces match each other, and so forth.

    It should also do that for each set of matching characters, (), {}, [], «», and, because I'm entirely unreasonable, <>, but only when they're being used as angle brackets. All of that apart from the conditional angle brackets support feels to me like it shouldn't be too difficult to do. At least, so long as one is doing ones matching characters matching in a real programming language. Some of these tools don't do that. If one is doing ones syntax highlighting and character matching using some kind of inner platform language, well, then one is cursed and basically asked for it. I understand an inner platform language can be "quicker" than doing it in ones main language, especially if that's something like C, but unless the inner platform language specifically has provisions for stuff this, it's an easier way to make a fundamentally buggy implementation. Programming languages are complicated and I don't think any of the inner platform languages I've seen for syntax highlighting can handle that complexity for their own language, let alone others.

  • June2025 (unregistered)

    A long long time ago I worked on a C project where the following was frequently seen : #ifdef SOMETHING if (some_condition) { #else if (other_condition) { #endif common_code(); } /* } */

    (we didn't have // comments)

  • (nodebb) in reply to dusoft

    I wish it were so, but I never found a clean way to have Visual Studio automatically change to tabs on checkout and re-change to spaces on commit; had to build a clumsy Git hook that puts the spaces back, and I must have programmed it wrong because it prevents me from doing partial commits.

  • (nodebb) in reply to Your Name

    How can anybody sane ever prefer tabs.

    Simple: I want to move between indentation levels with one arrow key press, not two and especially not four (or worse, eight). I want Tab followed by Backspace to be a no-op, not a space and especially not three (seven is right out).

    Ask any text editor control developer what a fine thing tabs are.

    I'm conscious it's a hard thing to do, I should try it once. Good news is, once it works, it works. Sure that's hell to program, but you know what else is? Programming in a C-style language with spaces.

  • (nodebb)

    I must confess, I prefer a tab to be 2 spaces not 4.

  • anonymous (unregistered) in reply to dpm

    Notepad is the ultimate text editor, second only to Microsoft word and nano.

  • (nodebb) in reply to Medinoc

    I finally got off my ass and fixed it.

Leave a comment on “Brace Yourself”

Log In or post as a guest

Replying to comment #684459:

« Return to Article