5 ms·

Code like this is interesting to me whenever I see it: const g = [['', '', ''], ['', '', ''], ['', '', '']] // grid Why not just be descriptive and call it `

• jonplackett 7y ago
  So many code examples have things like this and worse. One I saw the other day had about 10 variables created in one part and then these were all placed into another object that had the same names as all the variables. You also see a lot of examples with loads of other irrelevant code in them. Just keep it simple please!
• scelerat 7y ago
  "Code golf" https://en.wikipedia.org/wiki/Code_golf https://en.wikipedia.org/wiki/Code_golf
• rpunkfu 7y ago
  cries in golang
  • leetrout 7y ago
    For small functions / blocks and descriptive types I’m ok with it in Go BUT I always use descriptive names anyway. So much easier to keep context in my head.
    • libria 7y ago
      I thought the whole single-char-var thing was for very short-lived variables. I very much prefer for c in internalProductCategories p = fetchProductsInCategory(c.id) m = getAccountManagerName(c.id) results.append({categoryName: c.name, products: p, manager: m.name}) to for internalProductCategory in internalProductCategories products = fetchProductsInCategory(internalProductCategory.id) manager = getAccountManagerName(internalProductCategory.id) results.append({categoryName: internalProductCategory.name, products: products, manager: manager.name}) They're both clear, neither needs comments, but one is unnecessarily verbose.
      • Kaze404 7y ago
        The latter requires you to read the assignment to figure out what the variables mean.
        • ludamad 7y ago
          This is true, it is classic data denormalization - in the latter example, if all we want to gloss is the results appending, we need to read less
        • Silhouette 7y ago
          On the other hand, the former is much more scannable, so maybe that doesn't matter.
          • Kaze404 7y ago
            I don't understand what this means.
            • Silhouette 7y ago
              Just that the shorter names make for a more concise presentation, which in turn is quicker to scan than having to see and parse all the long names to reach the same conclusion.
      • ysavir 7y ago
        While that's definitely better than single letter variables everywhere, I still think an explicit variable name is better. In general, I follow a rule of "If I can't search the file for this variable and find it easily, it's a bad name".
        • Silhouette 7y ago
          Isn't this the standard argument for making names more specific as the scope where they are visible gets larger? Something only used within a short function, so it only ever appears within a few lines of where it's defined, can probably be very short or even a single letter, and that conciseness can be beneficial. Something used elsewhere in a file should probably have a more descriptive name, so it can be easily distinguished and located. Something exported from a module and used elsewhere in the program should probably have both the more descriptive element and then, one way or another, some further way to identify that it's the version from that particular module that is being used.
• JustSomeNobody 7y ago
  It wouldn't annoy me so much if they hadn't put the comment. I can clearly see it's a grid.
• brudgers 7y ago
  Aesthetically, it's consistent with the article. Technically it's consistent with ordinary practice. e.g. import naughtsAndCrosses as nan
  • gtf21 7y ago
    I'm not sure this is "ordinary practice", especially as `nan` often refers to "not a number" as an error category. Typing full words doesn't take that much longer than acronyms, and results in more readable code (although this is well enough established at this point that I don't think I need to go over it).
    • brudgers 7y ago
      Bugs are ordinary practice. Importing naughts and crosses is not. I giggled mischeviously when I wrote it. Particularly since it looked Pythonic. YMMV.
• pier25 7y ago
  Totally agree. Code should be stupidly obvious so that reading it consumes as less cognitive resources as possible.
  • bonestamp2 7y ago
    Yep, let the minifiers and obfuscators handle the minification and obfuscation.
• jackewiehose 7y ago
  I have no problem with abbreviations over a limited scope but looking at this code[1] I can't figure out what the author meant by 'm' and that makes me wonder if the author does know what he's doing. [1]: https://github.com/leontrolski/leontrolski.github.io/blob/master/33-line-react-with-comments.js https://github.com/leontrolski/leontrolski.github.io/blob/ma... edit: Ok, I should have read the article first. It's probably for https://mithril.js.org/ https://mithril.js.org/
  • leontrolski 7y ago
    Using m or h as VDOM constructors are mithril/hyperscript-isms, I guess that's not obvious if you not worked with those or similar libraries, sorry!
    • jackewiehose 7y ago
      yep, I figured that out by reading the actual article instead of straight jumping to the source and my edit was too slow. I'm sorry ;-)
• leontrolski 7y ago
  Author here - I did put a warning in guys :-) Lots of the code looks pretty code-golfy - I promise I don't do stuff like this at work, neither should you Happy to s/g/grid/ - writing the whole exercise felt a bit golfy TBH.
  • galaxyLogic 7y ago
    >> if you change the state, it runs the function again, this returns a new virtual DOM What do you mean by "change the state"? How do you do that? By calling some function, or perhaps by assigning a value to some property of a state-object? OR by calling the function again with a different state-object? Thanks
• grawprog 7y ago
  If that grid was going to be used in a single loop or something I may write it like that but any larger scope and it would definitely have a descriptive name.
• caymanjim 7y ago
  Comments in code are almost always an indication of poor naming choices. I don't get it either.
  • Supermancho 7y ago
    He saw grid in his head and thought g was fine since he was doing a minimal poc. It's not something that's hard to understand.