• (nodebb)

    When I worked with Forth, we had a standards document that specified no indenting of any kind was allowed. This is better.

  • Brian Boorman (unregistered)

    Programmer was probably a converted English major. You always indent the start of a paragraph. Each function is a paragraph of code, each file is a chapter, and each program is a book.

  • LZ79LRU (unregistered)

    I was ready to accept this under the banner of "if its consistent than what the hell" when I saw those braces.

    K&R Braces are the deed of the devil and need to die in a fire. And not the nice kind of fire either. Like one of those chemical fires that give out caustic fumes that melt your skin and ulcerate your lungs even as you burn.

  • BWill (unregistered)

    I had some reasons to hate Python. But the most stupid feature of all was that indentation had meaning and needed to be done manually.

  • RLB (unregistered)

    And anyone using GNU style is just evil.

  • (nodebb)

    I will not be surprised if somebody creates a language which flips (), [], {}, etc.

      void Foo)(
  }
// ... code ...
  {
  • Sauron (unregistered)

    Sure, the indentation is horrendous, but what matters is the logic.

    And the logic is not great.

    Hopefully, the codebase doesn't eat 1000x more resources than it should, segfault at random moments, etc. Who would be surprised?

  • (nodebb) in reply to LZ79LRU

    The braces themselves don't tend to bother me. Cuddled elses do.

    What's odd is that they bother me less in begin...end languages than in brace languages and I couldn't really say why.

  • LZ79LRU (unregistered) in reply to BWill

    Aye. That be its worst offense. Although I have seen my fair share of those over the years. Languages best left forgotten and buried. Code conventions best not of spoken. Horrors best left buried in the sands of time.

    For it is true what they say. If you gaze for long into an code, the code gazes also into you.

  • (nodebb)

    The great part is that the nodes are not actually chained. There is no line setting newNode->next.

  • Rod (unregistered) in reply to Sauron

    And the logic is not great.

    Such as allocating only enough memory for a pointer when what you need is a Node structure.

    Node* newNode = (Node*) malloc(sizeof(newNode)); newNode->data = data;

  • Barry Margolin (github)

    Reversing the direction of indentation isn't inherently evil, since the grouping is still apparent. The problem is that they only do this at the function level, not blocks. So you can't easily see the structure of the code.

    And the reason why the "normal" way is as it is -- you don't need to know the deepest level of nesting when you start writing a function. But an automatic indenter could keep adjusting as you go.

  • Sou Eu (unregistered)

    My biggest qualm about this indentation style is that you must know how many levels of indentation there are up front. Adding a line of code could mean having to reformat the whole file!

  • (nodebb) in reply to Rick

    Ah, the good old 70s. When spaces were consider way too expensive to be useful.

  • (nodebb) in reply to LZ79LRU

    Yeah, I prefer Allman as well; K&R always felt to me like someone really tried to save 1-2 bytes of an new line - or perhaps tried to fit some sample code onto a page.

  • davethepirate (unregistered)

    Probably a mix of spaces/tabs for indentation and someone decided to remove all the tabs.

  • MyActualRealName (unregistered)

    'And that's when I shot him, your honor.'

  • LCrawford (unregistered)

    I recognize a copy and paste into a brain damaged editor that indents with unintelligible rules.

  • (nodebb)

    To my Allman-style brethren/sistren - I love you; I thought I was all alone (ಥ﹏ಥ)

    I went through the 5 stages of grief when I realized that Go's fmt command enforces K&R style.

    Now I am just a numb unfeeling automaton, dead inside, reduced to using K&R style everywhere...

  • Pauller (unregistered)

    On spaces vs tabs, I prefer spaces. I use multiple tools for source code - I may use an editor from one vendor, and compare / merge from another, a grep from a third, etc. And none of the tools agree on how to format tabs. The merge tool can break source formatting because it uses spaces, etc.

    Using spaces generally lets everybody play nice.

    YMMV

  • vegetaman (unregistered) in reply to The Beast in Black

    Glad to know us Allman users are not alone. There's dozens of us... on here, at least!

  • (nodebb)

    Something annoying I've seen in some repositories is

    int main()
{
 int x;
 for(x=1;i<10;i++)
 {
  printf("%d\n", i);
 }
}

    I hope it is just bad formatting of tabs in the browser, but it makes reading source code directly on the web very annoying.

    Addendum 2023-06-21 15:58: Alternatively without any indentation at all, at which point I assume that client-side code formatters and a weird normalization before committing are involved.

  • Fizzlecist (unregistered) in reply to MyActualRealName

    "It was a mercy killing"

  • (author) in reply to Pauller

    TRWTF are tools that don't automatically respect the indentation in the file.

  • Randal L. Schwartz (github)

    I'm a happy K&R camper, given that the white C bible was my first real language to learn after shell scripting. I'm also happy that we helped make it the preferred style for Perl programs. I'm also happy that in my new life as a Dart and Flutter programmer, the one true formatter for Dartlang again uses the One True Brace style of K&R. Life's been good to me so far...

  • Randal L. Schwartz (github) in reply to Randal L. Schwartz

    Forgot this: I'm also happy that while I'm annoyed at "indent as syntax" like in Python and ugh YAML, I'm happy that at any moment in YAML I can drop in to extended-JSON mode, and stop caring about indentation entirely.

  • Marian (unregistered)
    Comment held for moderation.
  • LZ79LRU (unregistered) in reply to Pauller

    And that is precisely why you should always use tabs and not spaces.

    Whitespace is not just an artistic statement on part of the coder. It is a readability and usability tool. And different people have different needs when it comes to that.

    One person on your team might have a small laptop monitor or even phone to read your code on. He wants and needs as little whitespace as possible that still conveys the message of indentation.

    At the same time another might be vision impaired and require a lot of whitespace and a large font to see anything. They want large tabs with wide spacing that makes things clear. And this is not a joke, I have seen this. I my self have been using a larger than standard zoom levels for years now.

    And this is where tabs vs spaces comes in. Spaces are characters with a specific fixed size. By using spaces you are forcing the reader to read the code in the exact format you wrote it in.

    Using tabs and only tabs on the other hand allows the reader to configure his local system to display things in a way he feels comfortable and needs without effecting anything in the code.

    So as much as spaces tickle our developer OCD by letting us format things precisely using tabs is much more usability friendly.

  • Simon (unregistered) in reply to R3D3

    I don’t see your problem (unless it’s the bug, x versus i)

  • (nodebb) in reply to Rod

    The other bug is that the old list gets thrown away in a memory leak. You are only ever looking at the last node generated.

        void push(Node** headRef, int data) {
Node *newNode = (Node *) malloc(sizeof(newNode)); 

newNode->data = data;
newNode->next = *headRef;  /* This is the link in your linked-list! */
*headRef = newNode;
    }

    Would it kill anybody to leave an extra blank line in some places to make the separate logical components easier to identify?

    Addendum 2023-06-22 04:47: Arrg! I left the malloc using sizeof(newNode). That needs to be sizeof (Node).

  • (nodebb) in reply to LZ79LRU

    At the same time another might be vision impaired and require a lot of whitespace and a large font to see anything. They want large tabs with wide spacing that makes things clear. And this is not a joke, I have seen this. I my self have been using a larger than standard zoom levels for years now.

    Ultimately, only half-true. Programs could treat leading spaces special, just like they treat tabs (anywhere) special. I actually used this before myself in Emacs, to allow displaying org-mode or markdown text in a serif font, but format leading spaces with a fixed-width font to keep the indentation consistent (and sufficient -- variable-width fonts typically have the spaces around or less than half as wide as fixed-width fonts).

    That said, the true half is that many programs allow choosing the tab width, but choosing the width of leading spaces is nothing I have ever seen before outside my own special-purpose solution.

    That said, the real solution should be to decouple code-formatting from code-storage. There is no need for the files to contain indentation at all, only line breaks for being able to produce diffs. The indentation could be left entirely to the viewer, whether it is an editor or a web-based viewer for code reviews. [...]

  • (nodebb)

    [...] It would break specific case, such as some multiline code constructs like

    int exit_code = 0; // this line is
                   // important I guess.

    but most multi-line comments anyway have the same indentation before the comment character, so it shouldn't be too much of an issue. The exception being guarded multi-line comments like

    /*
 *
 */

    in JavaDoc, but those cases could still be left to a Java-aware code formatter.

    So in a sense, TRWTF is that in 2023 we are still hard-coding indentation into repositories. And Python is a WTF for requiring it.

    Always feels like Python tried to enforce consistent indentation, but got confused about how to do it well. Also, it is still sort of inconsistent, because it allows at least all of

    if True:
␣␣␣␣do()
if True:
␣␣do()
if True:
⇥do();
  • holy shit now I'm actually commenting here... (unregistered)

    Always a joy when the cursor flies off the line because tabs give the arrow keys a boost.

    Or when you type space and nothing happens because you're typing into a tab.

    Or when you type a single space and the rest of the line jumps away because you happened to move a tab across a tabstop.

    I do get all the accessibility concerns, but for me at least tabs just make life hard. And that's already before multiple programs come into play.

  • LZ79LRU (unregistered) in reply to R3D3
    Comment held for moderation.
  • (nodebb)

    But also enforced tabs, because tabs let your IDE indent how you want, spaces don't. Spaces are wrong.

    I love you.

  • Vim (unregistered)

    This is an issue that I hit not-infrequently with vim. I search for something, and vim says, "Reformatting ..."

    I don't know what it is. Some random key, which I've never found, apparently hit before doing a search, causes vim to unindent every matching line -- or perhaps every line. Or every line not starting with a comment. I really don't know.

    Normally I notice it immediately and just hit "u", but there has been at least one case where I did not notice it, and saved the file. :-(

    This looks like that.

Leave a comment on “Dented”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article