This isn't a public project to write an open source Rust RDP client, it's the result of a company selling cloud software open sourcing their RDP stack. It stands to reason that things like comments and documentation aren't as extensive, because the goal isn't to attract maintainers per se, but to provide context to employees working on the code. I find the READMEs to be more than informational enough for that purpose.

The RDP implementations I've seen are in unsafe languages like C. With the history of memory exploits in RDP (targeting both servers and clients), I think RDP code written in a language where memory bugs don't immediately lead to security issues are an advantage here.

The code also readily compiles to WASM and can be used from within a web browser, which isn't as easy when you need to bundle all the dependencies for a project like freerdp.

As for the comments, they're not great, but the style isn't that uncommon. Documentation is rarely written to explain the program to you, most developers I know write comments to explain the things that may not necessarily be clear by code alone. The expectation for most software developers is that you're ready to read the code if the docs aren't clear immediately. I much prefer extensive documentation, but I have to admit that I've run into issues more than once because nobody bothered to update the extensive documentation above a function after several changes, leading to inconsistent behaviour. A failure of the code review process for sure, but these things happen in software projects, unfortunately.

In my experience these are often generated by IDEs, AI or, the result of including comment coverage in KPIs. They can sometimes be useful, though, like when you write a Rust function declaration with lifetimes and generic types, where notation becomes quite difficult to read.

I wonder if that comment is a result of vibe coding. LLMs often fill their code with comments that restate the literal behavior of a line of code rather than explaining it in a way that adds value.

"I shouldn't have to read code to understand comments"

That's fair, but that's not universally agreed. Some say comment the "why" not the "what" because you can always read the code to understand the what. Also, code will likely be more correct than the comments if code is modified, and the comment isn't. And finally an entirely different school of thought is that you don't need comments if you name your functions right, breaking every few lines, the thing you would have otherwise commented on, into its own function with a good name.

I think all of these are good suggestions to some degree. I'm somewhere in between, leaning toward more comments to help the AI

"I read comments to understand code"

I read some of your repo. You write a lot of comments. Your response also describes reasons why I avoid reading comments. I think your preference comes off as an attack on different approaches. I attempt to code so clearly that I do not need to document as the code is self documenting. And the code you're talking about is probably AI written. I don't let AI comment on my code unless told to.

fyi your website is down or too slow.

Three slashes makes it a doc comment, just so it shows up nicely here https://docs.rs/ironrdp/latest/ironrdp/core/struct.WriteBuf....

It being FOSS means you can fork and customize it.

Maybe instead use it as a headless automation tool.