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.
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.