Rust Wiki

Revision Difference

CSharp_Formatting#526798

<cat>Dev.Modding</cat> <title>CSharp Formatting</title> # Who cares about formatting? I understand my code! Take a look around. All the code your are basing your mods on has been written by other people. The reason you were able to get to this point was by other people being considerate enough to write code other humans can understand. **Code is made for humans. Assembly language is made for computers** It doesn't matter how long or short your variable names are, how much white space you use, how long or short your code files are. All that matters is that other humans can understand what you have written down. Don't be lazy and write poorly formatted code to save time in the short term only to lose 10x the amount of time later on trying to work around the mess you have created. Trust me: you are not saving time. And as a last warning: that sucker who is navigating through your web of code, cursing your name while furiously writing comments to explain 300 line functions and complete lack of classes will likely be **you**. You will not remember why you wrote something 6 months, 1 year, or 3 years ago. So treat that future person like you would want to be treated because it very likely be you. So treat that future person like you would want to be treated because it *will* be you. With that 'motivational' speech out of the way, what guidelines should you actually follow? # Variables In Classes ##TLDR: ##TL;DR: ___ * **Capitalized** means publicly accessibly * **Capitalized** means publicly accessible * **Lowercase** means only accessible inside class * **Underscore before the variable** means internal use and don't touch if you don't need to ## Details ___ The purpose of naming schemes is to make code more readable and to describe the function of a variable by looking at it's name. There are standards that most people will agree on and understand. ##Public: ___ **VariableName** Use CamelCase and always keep the first letter uppercase. ##Private ___ **varibleName or _variableName** **variableName or _variableName** Use camelCase. Underscores `_` can be put in front of the variable name if preferred. ## Internal: ___ ** VariableName or variableName** Use CamelCase. Only used when making a seperate DLL ( eg. Extension in oxide ) so not too important. **VariableName or variableName** Use CamelCase. Only used when making a separate DLL ( e.g. Extension in oxide ) so not too important.