• Time Troll

This would probably cause a compiler error…

But assuming it doesn’t the context is p_ch = the bits above… the code declaring p_ch isn’t shown but I’m guessing that the value here is actuality a pointer to a pointer so nothing illegal would be happening.

Lastly… C++ is really lacking in guarantees so you can assign a char to the first byte of an integer - C++ doesn’t generally care what you do unless you go out of bounds.

The reason I’m casting to void* is just pure comedy.

What I meant was:

In the screenshot it said x = *(++p) and iirc that is not the same as saying x = *(p++) or x = *(p += 1)

As in my example using ++p will return the new value after increment and p++ or p+=1 will return the value before the increment happens, and then increment the variable.

Or at least that is how I remember it working based on other languages.

I’m not sure what the * does, but I’m assuming it might be a pointer reference? I’ve never really learned how to code in c or c++ specifically. Though in other languages ( like PHP which is based on C ) there is a distinct difference between ++p and (p++ or p+= 1)

The last two behave the same. Though it has been years since I did a lot of coding. Which is why I asked.

I’ll install the latest PHP runtime tonight and give it a try xD

Yes.

p++ == p+= 1 == p = p + 1 are all the same if you use it in an assignment.

++p is different if you use it in an assignment. If it’s in its own line it won’t make much difference.

That’s the point I was trying to make.

Not if you’ve done a lot of pointer math

Ah bowel movement…

It could be a fart brewing

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;
       }
_ => {},
}

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.

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;
        }
_ => {},
}

This point advocates against the use of mod with content in a file unless it is used for a testing module. A common pattern is to have the unit tests for a module inside the main module file. Tests in rust are just specially tagged functions. To avoid compilation costs in non-test builds and false unused code warnings you can put all test related code in a submodule and tag that module with #[cfg(test)]. That way the module will only be included and compiled if the crate is being compiled to run tests.

The Star wars thing refers to scrolling long text files similar to the intro of the starwars movies where a long text is scrolled for the viewer.

Oh, then you use and_then() or something similar.

There’s also the possibility to use the guard clauses patern and do let <...> = <...> else {}.

And finally, you can always split into another function.

It’s not straight rules. It depends on what makes it more readable for your case.

Oh, yeah, I meant that it makes two characters into one big one, visually reaching across two or three widths, or just having one of the characters larger than the usual grid, e.g. in := the equals sign reaches into the width of the colon.

This reminds me of a recent Microsoft font¹, so naturally here’s a rant about that: They developed a feature, called “texture-healing”, which basically allows characters that normally need to cramp into one monospace width, like m or w, to reach into the space of neighboring characters, if those neighboring characters are narrow, like an i.

In theory, not a terrible idea, but then you get this kind of hate crime:

Obviously, might just be me again, but not having these letters align, just looks so much worse to me.

¹: It’s this font: https://monaspace.githubnext.com/

Sure, I could get used to it. But it being more readable is not even true for me, because the thing I got used to instead, is that != is the unequals-operator. I see that much more often than ≠.

I’m sure you are capable of rewriting that in 3 lines and a single nested scope followed by a single return. In fact in languages that use exceptions you have to use at least one subscope.

Notice that in my example I didn’t even broach the example with error conditions, cause it’s trivial to write cleanly either way. Instead I talked about returns inside business logic. You can’t unfuck that. 🐞

I don’t think it’s worse, I think it’s equivalent. Also I don’t like the risk of resource leaks which is inherent to multi-returns beyond input validation. And that’s true beyond C because memory isn’t the only resource that can be leaked.

It’s not about how readable the branches are, it’s about having to read all of them to ensure you understand the control flow so that you don’t leak. Length of functions is a red herring. You want me to read the contents of short blocks to ensure the control flow is correct. I don’t want to read the contents of those blocks, other than the conditional and loop statements. Reading short blocks is better than reading long blocks. Reading just the control flow lines is better than reading short blocks.

Early returns are very similar to gotos. One level of nesting to take care of validation is trivial in comparison. You’re replacing logical clarity for minimal visual clarity. This is true regardless of the size of the function which shows that the size of the function isn’t the determinant. You’re not alone in your opinion, clearly, and I’m not going to convince you it’s a bad practice but I’ll just say what I think about it. 😅 This practice doesn’t make it my team’s codebase.