Reason for the use of inconsistent Hungarian notation and lack of namespaces + Style Guidelines? about gamenetworkingsockets HOT 5 CLOSED

(what does the H in HSteamListenSocket mean for example)
H is for Handle

I'm guessing some of the code was just so old (comments indicate 2005) that previous convention was followed? Another thing I notice is how namespaces are not used(at all?) when there doesn't appear to be a reason they shouldn't be, IE here, in what I assume is supposed to be the "valve std lib" folder.

Anything not directly labeled "SteamNetworking" can likely be considered to be well-tested, working legacy code. Pull requests into libraries such as tier0/1 or vstdlib will likely need extreme care as if Valve were to pull them back upstream they would be eventually backing the entirety of their C++ codebase. Changing even just a typo in one of those could result in hours of work for Valve due to potentially updating hundreds of locations in their code, across multiple repos, etc.

Would it be acceptable to for me to make changes to incorporate namespace resolution where appropriate, and remove Hungarian notation entirely? Since there's no reason I or anyone else couldn't do this, I don't see a need for this to be taken on by the repo owners.

I wouldn't advise it. This is consistent with the rest of Valve's code, and they (nor I) likely wouldn't appreciate deviating from it.

_t suffix on things like CellID_t, not sure why, guessing stands for tag?

It stands for type, generally used for typedefs.

k_ stands for konstant

I'd recommend watching this video:
https://www.youtube.com/watch?v=wf-BqAjZb8M

from gamenetworkingsockets.

Hey, at least it's V_xxx instead of Q_xxx, which is what it used to be and that can still be found in lots of the Valve code. (The Q stands for Quake, BTW.)

As @rlabrecque said, this code has history and context. We intend to keep some of it in sync with the main Valve Perforce depot, which is powering the Steam client, the Steam servers, Source2 engine (Dota and the upcoming Dota card game) as well as CSGO and team Fortress, etc, etc. If you look in the tier0, tier1, vstdlib folders, etc, you are going to see how the sausage is made. I would advise against that.

So in that context, the wisdom of making sweeping cosmetic changes for the purpose of making things more modern and more consistent is really a no-brainer practical engineering decision.

The other bit of context is that the main purpose of this lib is to provide the same interface as will (eventually) be provided in the Steamworks SDK. (A version of these libs are available to steam partners in a sort of early-access). We are releasing this code for that reason, so it's sort of necessary that the interface be textually consistent with the SteamworksSDK, which has its own style, for better or worse.

from gamenetworkingsockets.

what kind of contributions are you wanting to see?

The most useful issues and pull requests would be related to a bug in the software that causes it to not work as intended. E.g. something that an end user could detect. This code has shipped and has been used by millions of people playing CSGO and Dota, so most likely they would be caused by a use case outside of our design parameters, or some edge case our code hasn't hit, or some other platform, or because of how we have extracted the code from the main Steam branch.

As for problems that end users cannot detect, the most useful category would be problems with the code not compiling or working or being awkward to use on [Platform X].

So I guess in summary, the most useful feedback will be coming from people who are having difficulties using this code in some larger project, and the issue is a practical one causing the code to not fulfill their needs.

from gamenetworkingsockets.

Ah, that makes more sense. Thanks, for clarifying.

from gamenetworkingsockets.

I'd like to add to Fletcher's comments...

We would definitely be interested in changes that improve the design or add interesting features as well, not just bugfixes and portability stuff. But things like coding style and modernization of the code are probably not going to get much traction because it causes more problems than it solves (maybe not for this project directly, but for the code we have to sync it from/to).

from gamenetworkingsockets.