• Doods@infosec.pub
    link
    fedilink
    arrow-up
    2
    ·
    7 months ago

    A single match statement inside a function inside an impl is already 4 levels of indentation.

    How about this?

    The preferred way to ease multiple indentation levels in a switch statement is to align the switch and its subordinate case labels in the same column instead of double-indenting the case labels. E.g.:

    switch (suffix) {
    case 'G':
    case 'g':
            mem <<= 30;
            break;
    case 'M':
    case 'm':
            mem <<= 20;
            break;
    case 'K':
    case 'k':
            mem <<= 10;
            /* fall through */
    default:
            break;
    }
    

    I had some luck applying this to match statements. My example:

    
    let x = 5;
    
    match x {
    5 => foo(),
    3 => bar(),
    1 => match baz(x) {
    	Ok(_) => foo2(),
    	Err(e) => match maybe(e) {
    		Ok(_) => bar2(),
    		_ => panic!(),
    		}
    	}
    _ => panic!(),
    }
    
    

    Is this acceptable, at least compared to the original switch statement idea?

    • RustyNova@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      7 months ago

      It’s a lot less readable imo. As well than a cargo fmt later and it’s gone (unless there’s a nightly setting for it)

      • Doods@infosec.pub
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        Formatters are off-topic for this, styles come first, formatters are developed later.

        My other reply:

        How about this one? it more closely mirrors the switch example:

        match suffix {
        'G' | 'g' => mem -= 30,
        'M' | 'm' => mem -= 20,
        'K' | 'k' => mem -= 10,
        _ => {},
        }
        

        How about this other one? it goes as far as cloning the switch example’s indentation:

        match suffix {
        'G' | 'g' => {
        	mem -= 30;
               }
        'M' | 'm' => {
        	mem -= 20;
               }
        'K' | 'k' => {
        	mem -= 10;
               }
        _ => {},
        }
        
        • folkrav@lemmy.ca
          link
          fedilink
          arrow-up
          3
          ·
          7 months ago

          I mean, I use formatters everywhere I can exactly so I don’t have to think about code style. I’ll take a full code base that’s consistent in a style I dislike, over having another subjective debate about which style is prettier or easier to read, any day. So whatever cargo fmt spits out is exactly what I’ll prefer, regardless of what it looks like, if only for mere consistency.

    • calcopiritus@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      7 months ago

      Well, of course you can have few indent levels by just not indenting, I don’t think the readability loss is worth it though. If I had give up some indentation, I’d probably not indent the impl {} blocks.

      • Doods@infosec.pub
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        6 months ago

        I just got some idea yesterday regarding impl blocks, ready to be my respondent?

        I had a big impl block with 4 levels of indentation, so I cut the block, and replaced

        impl InputList {
            //snip
        }
        

        with mod impl_inputlist; and moved the impl block to a new file, and did not indent anything inside that block.

        The advantage this has over just not indenting the impl block in place, is that people will have difficulty distinguishing between what’s in the block and what’s outside, and that’s why the impl was moved to its own exclusive file, impl_inputlist.rs

        Maybe I am overstressing indentation. Ss there something wrong with my setup that prevents me from accepting 4-space indentation?

        I use:

        Editor: Neovide

        Font: “FiraCode Nerd Font Mono:h16” (16px fonts are addicintg)

        Monitor: 1366x768, 18.5 inch, 10+ years old, frankenstein-ly repaired Samsung monitor.

        Distance: I sit at about 40-60 Cm from my monitor.

        That leaves me with a 32x99 view of code excluding line numbers and such.

    • lseif@sopuli.xyz
      link
      fedilink
      arrow-up
      2
      ·
      7 months ago

      i personally find this a lot less readable than the switch example. the case keywords at the start of the line quickly signify its meaning, unlike with => after the pattern. though i dont speak for everybody.

      • Doods@infosec.pub
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        7 months ago

        How about this one? it more closely mirrors the switch example:

        match suffix {
        'G' | 'g' => mem -= 30,
        'M' | 'm' => mem -= 20,
        'K' | 'k' => mem -= 10,
        _ => {},
        }
        

        How about this other one? it goes as far as cloning the switch example’s indentation:

        match suffix {
        'G' | 'g' => {
        	mem -= 30;
                }
        'M' | 'm' => {
        	mem -= 20;
                }
        'K' | 'k' => {
        	mem -= 10;
                }
        _ => {},
        }
        
        • lseif@sopuli.xyz
          link
          fedilink
          arrow-up
          2
          ·
          7 months ago

          the problem is that, while skimming the start of each lines, nothing about 'G' | 'g' tells me that its a branch. i need to spend more time parsing it. mind you, this may simply be a problem with rust’s syntax, not just ur formatting.