![]() ![]() Who cares about that? I want to make an Button actually interact with something. I remember when I first started coding, Hello World tutorials I couldn't even figure out, because they taught me nothing important at all whatsoever except how to make DOS say Hello World. I always learn better with something tangible I can interact with, not a Hello World thing. for 100 bucks) just so I could look at the code and learn. Granted I'm not teaching them with my Assets, however, I've bought a many of things just so I could learn how it was coded, even if I never used it in a real practical sense. I don't try to not comment on my Assets, because I'm not the type of person to prevent people from learning how things are made. So people know exactly what every single thing does in detail. (Like literally almost every single thing has comments). Well I always heavily document code for Asset Store Scripts. I hardly ever document something unless it's something new I am learning. If another engineer asks you wtf you're doing in that code, then you should probably comment it. If you are creating an API for another client, by all means, comment your code with doxygen style comments for class headers, functions, and public variables if necessary. There is no need to obscure the code during production development. If it proves to be a problem later on, profile it, and optimize it as necessary. If you are concerned about performance by breaking up the math operations into separate lines, don't be. If the class/function is too short to break up, the contents are either self explanatory, in the case of accessors, or probably obscure enough to require some comment, like a single line of math operations, which is already inadvisable anyway. ![]() If a function is too difficult to understand and too long, break up the function into several functions with well named function names. Name your functions so that they describe what they're doing. The only exception I make to this rule is with "for loop" counters. Properly name your variables so that they indicate what they are for. Programmers should strive to make the code as self-documenting as possible. Excluding comments won't make your code run faster than if your code had comments. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |