7 ms·

> I don't see comments helping me... I don't know why people say this type of thing, as if there's some choice you have to make between good names and comments

• vinceguidry 11y ago
  > there are absolutely times when comments are necessary. I'll have to take your word for it, because I've yet to run into that situation.
  • work-on-828 11y ago
    I find that sometimes I am diving into a codebase and wish I had a higher-level map of where things are.
  • javajosh 11y ago
    A good marker for when comments are going to be useful is when something stumps you, and then you fix it and/or figure it out. Chances are, when you read the code again it will stump you again - or on re-reading you might not even realize there was an issue. So I comment the change. It's usually something simple like, "This cast avoids a special case in method X", or along those lines. The comment is the "why" where the code is the "what".
    • vinceguidry 11y ago
      If I run into that situation, I refactor the code so that I can better understand it the next time. To not do so is to waste all that time you spent understanding it. > It's usually something simple like, "This cast avoids a special case in method X", or along those lines. If I had an issue like that, I'd fix method X to be more accepting of unclean inputs.
      • tbrownaw 11y ago
        The problem is that method X is a remote invocation into another system that has different change-control procedures, a different ticketing system, and a different release schedule.
        • vinceguidry 11y ago
          I'd use a gateway class and intention-revealing method names, even if all that method was doing was casting a value. I'd call it ".edge_case_fix", (but described better than "edge case") and do the same for every weirdness in the external system that requires workarounds.
  • jimbokun 11y ago
    I find one place where comments are absolutely critical is in external facing APIs. Summary of the purpose of the API, purpose of each method, valid arguments and possible return values. Think how often you need to read the comments for whatever libraries and APIs you use in your work.
    • vinceguidry 11y ago
      I deal with two types of APIs. Well-documented and otherwise. For well-documented APIs, I can simply re-read the documentation to figure out the other side of my code. For the rest of it, I try to write as cleanly as possible, and as robustly as possible the first time, so I'm not in the dark the next time I have to look at it. If I have to take time out to re-understand how it works, I'll just take the time and not feel guilty about it. The company wanted me to use that dreck, I'm not going to feel bad about having to take more time with it. I don't think comments would help much in the second situation given decent engineering the first time around. If it's my code, I'll usually recall the idiocy I had to work around when running down whatever issue had me looking at it again.
  • ghthor 11y ago
    Comments are incredibly useful for that bit of code that you spent hours trying to make it work and you couldn't figure out a way to name things well or to improve it. That's where a comment is priceless.
    • vinceguidry 11y ago
      Maybe it's because I write in Ruby, and so never have to do any tricky optimizing, but if solving a particular problem starts to run over a half hour, I look to re-architect the project, either by reaching for a gem or telling my boss that X is too hard and we should do Y instead. My patience for going down rabbit holes has mostly gone over the last year. Also, again perhaps because I use Ruby, it never takes me more than a few seconds to name something. If it does, then it's a code smell and I go looking for the missing class.
      • baltar 11y ago
        I don't see how Ruby saves you from optimising (to my limited knowledge, it's not exactly a fast language), but I agree with you that naming stuff sensibly and extracting functions (which you can then name sensibly) is most important for maintainability and can make "in-code" comments unnecessary in many cases. However I strive to always document what a function does if its not obvious -- though I'd call that "documentation" and not "comment". Example for obvious: Int add(Int x, Int y) in a typed language. Example for not obvious: add(x, y) in an untyped (or "dynamically typed") language (Does it auto-coerce? How? Can it add complex numbers? In my particular representation? ...). Someone mentioned that sometimes comments are useful e.g. to document a quirk/bug in library function you call, and I have some examples of that in my own code. But most often you should be able to rectify that by wrapping said function in your own one that omits the problem. If a function seems impossible to give it a sensible name that isn't ridiculously long, split it up. The more clear code of the individual parts and how they are combined should give a hint of what is actually computed here. Maybe it's a new concept in your business logic, in which case providing a clear and exact definition makes sense anyway (put it into the appropriate place in your documentation). This whole procedure can take a significant amount of time, but it will be worth it in maintainance!
  • ehnto 11y ago
    When you are using a particular method that is required by the context of your work rather than code you have control over. Perhaps the method name in the framework you are using is non obvious, or there is a bug in the way it works. Sometimes comments are just to save future you some time or help other developers find context. Suffice to say any project of significant complexity will probably require comments at some point. That complexity can come from the code, the task, the stakeholders or the dependencies. Unless you are happy with a method name like getSimpleProductInstanceThroughCoreFactoryBecause ModuleRewriteWillBreakCompatibilityWithSecurity PatchSUPEE5523 () In that case I guess you're right. Edited to stop the method name stretching HN layout.
    • vinceguidry 11y ago
      Break the long method up into multiple methods, each implementing a different fix. Bundle these methods up into a gateway class.
      • ehnto 11y ago
        That introduces unnecessary complexity in the code for something that could just be explained in a comment. There were no fixes performed in the method, the method just gets a product instance from a factory. The comment gives reasons for why it was using a core factory directly instead of using the automatic object resolution mechamisms. The real method name was getProductInstanceFromCoreFactory. Still long, still clear as to what it is doing. But making the context clear would be more code than it is worth. Avoiding comments by writing clearer code isn't a bad habit, but my point is that they are very useful to provide context for something that getting context for would otherwise be erroneous or cumbersome to implement.
  • ars 11y ago
    Comments are not for how or what, the code does that just fine. Comments are for why. Sometimes the why is obvious, then you don't need a comment. The rest of the time, add that comment. Even if it's something like "Steve in accounting asked me to put this in."
    • unclebucknasty 11y ago
      Good comments do frequently answer the why question and, sometimes, the non-obvious what. It's generally true that the code expresses the what, but it's also true that it can take the reader time to discern. A simple comment here and there can be a shortcut to this discernment which, over thousands of lines of code can save serious time.
    • ajuc 11y ago
      Such comments are best added in commit messages. If you add JIRA task number to each commit it's almost always already there (because in the task there will be your discussion with Steve). And when you change the line because Tom asked you to change it again - you don't need to remember to remove the comment about Steve.
      • collyw 11y ago
        Sorry, but that is ridiculous. I have recently started working on an existing project which is all new to me. Having to go through git commits looking for relevant comments is just a silly suggestion. Its far more useful when I am browsing through the code, trying to understand it, to see a comment beside the relevant piece of code, not hidden away in git commit messages.
        • ajuc 11y ago
          No need to apologize for different opinion. IMHO comments aren't there for newcomers. You are a newcomer for a month or 2. You are a developer for years most often. Besides, how is //Steve in accounting asked me to put this in foobifyTheBaz(bazPtr, foobificationParams); more helpful for newcomers than just foobifyTheBaz(bazPtr, foobificationParams); Comments answering "why" are very important when bugfixing/changing stuff. You want to know if sth was intentional or just accidental, and if it was part of the change that you have to override, or some independent change, so you know which behaviour should stay, and which should change. You should always look at the git blame of the region you change anyway before making a change (it often turns out your change was there before and commit message has the reason why you shouldn't change it back). And you don't look for git commits. You enable git blame annotations in your IDE and hover over the relevant lines to immediately know who, when, and why changed that particular line. That's why commit messages are as important as good naming IMHO. By the way, when you have code like: //Steve in accounting asked me to put this in foobifyTheBaz(bazPtr, foobificationParams); barifyTheBaz(bazPtr, barificationParams); if (mu(bazPtr)) { rebazifyTheBaz(bazPtr); } How do you know which lines the comment refers to and if you should delete it or not when Tom asked you to change barifyTheBaz invocation? That's the main advantage of commit messages over comments - they are always fresh and encode the exact lines they refer to.
  • tbrownaw 11y ago
    /* Yes, this is wrong. The output goes in the db and needs to match /path/to/code/in/other/system.ext */
  • JabavuAdams 11y ago
    1) Vector3 computeNewtonianGravity(float massA, Vector3 positionA, float massB, Vector3 positionB); Which way does the returned force vector point? Towards mass A, or towards mass B? 2) Vector3 UnitVectorWithDirection(Vector3 originalVector); What does this function do when the magnitude (length) of originalVector is zero? 3) float ArcTan(float x); What is the allowable range of values for x? ...
    • dougk16 11y ago
      While I don't agree with the general sentiment of vinceguidry (e.g. I think comments answering "why?" are very important), for your specific counterpoints I do tend try solve it in code if possible: 1) Vector3 calcNewtonianGravityToB(float massA, Vector3 positionA, float massB, Vector3 positionB); 2) Vector3 unitVectorWithDirection(Vector3 originalVector_mayBeZero); vs. Vector3 unitVectorWithDirection(Vector3 originalVector_throwsIfZero); (if in a supporting language, throws declaration would also clarify). 3) float ArcTan(float x_throwsIfZero); or float ArcTan(float x_returnsNaNIfNot0to1), etc. This assumes: (a) You're not working in a language or environment that supports range constraints in the first place, cause if you are then that's ideal. (b) You're working on personal code or a small team. If you're writing code for public consumption you have no choice but to add detailed API documentation if you want to be successful, even if it's not DRY.
      • deleted 11y ago
        [deleted]
    • joshvm 11y ago
      The sibling comment about renaming is good - particularly with regard to the first function. However I think the other two are better suited to documentation rather than trying to make the function signature explain itself. Sooner or later you'll just remember that it takes a float, not the variable name. Certainly calling things like "x_returnsNaNIfNot0to1" works, but I find it a bit ugly and it gets complicated if you have multiple or more complex constraints. This is where languages with docstrings are nice. In Python all I would do is add a """ comment describing the inputs and the return values. You then have a) a comment describing the code; and b) documentation that's standard so people can pull it up with pydoc or ? in Ipython. When I'm working in Jupyter, I often hit shift-tab to check what a function is expecting.
• lunchTime42 11y ago
  The problem is the bug catch creep growing around DataInput and mathematical operations. I think it would really help to have a language, that differs between the original methods raw body (displaying the pure intentions) and blends out the various filters and catchy expeption handling. Such a function with catchy names, could be allmost as good as a coment- and is usually there. Coments can be useless too /* Function taking these arguments, returning this type */
• lmm 11y ago
  I think a lot of coders jump to comments as a first resort rather than trying to make the code clear. In theory it's not a tradeoff, but in practice I've seen a lot of heavily-commented code with single-letter variable names. My rule of thumb would something like "never write a comment until you've spent at least 5 minutes trying to make the comment unnecessary".