8 Matching Annotations
  1. Jun 2023
    1. Depends on the style guide you follow for your project. The popular Ruby Style Guide says to "Avoid using Perl-style special variables (like $:, $;, etc. ). They are quite cryptic and their use in anything but one-liner scripts is discouraged."
    2. When I first got started with Ruby, I obviously thought that $LOAD_PATH was better. But once you've graduated from beginner status, I'd only use $LOAD_PATH if I was trying to make my code more readable to a beginner. Meh its a trade off.
    3. The Ruby load path is very commonly seen written as $: , but just because it is short, does not make it better. If you prefer clarity to cleverness, or if brevity for its own sake makes you itchy, you needn't do it just because everyone else is. Say hello to ... $LOAD_PATH ... and say goodbye to ... # I don't quite understand what this is doing... $:
  2. Jun 2021
  3. Oct 2020
    1. first sighting: use of superscripts like this

      I like it. Nice and concise and understandable.

      • s¹  critical
      • s²  important
      • s³  nice to have
      • s⁴  low
      • s⁵  inconvenient

      But in other cases, the abbreviation is quite unclear and ambiguity:

      Like, what does "pr" mean in these cases?

      priority? Doubt it.

      • pr¹  chore
      • pr²  docs
      • pr³  feature
      • pr⁴  fix
      • pr⁵  performance
      • pr⁶  refactor
      • pr⁷  style

      Pull Request? Doubt it. But maybe?


      For axes that are quantifiable, like severity, using a number makes sense. But what benefit is there in including a number in these (platform?) labels?:

      • p¹ ⋅ browser
      • p² ⋅ linux
      • p³ ⋅ mac
      • p⁴ ⋅ windows

      I think this would have been better and clearer (in that fewer people would be like huh? and wonder what it means):

      • platform: browser
      • platform: linux
      • platform: mac
      • platform: windows
    1. In mnemotechnic,brevitasrefers to the creating ofsuch ‘‘rich’’ if necessarily ‘‘brief ’’ units. Because there is in principle no limiton the number ofdivisionesa person may have in memory, readers could beencouraged to make ‘‘brief and compendious’’ summaries of materials theyhad learned.

      This is very similar to the idea in TiddlyWiki or Zettlekasten of writing down and storing the minimal amount of information on a card to capture an idea.

  4. Feb 2014
    1. Beginning the issue with “are” or “is” often leads to a clearer and more concise expression of the issue than beginning it with “may,” “can,” “does,” or “should.” The latter beginnings may lead to vague or ambiguous versions of the issue. Examine the following alternative statements of the judicial issue from Aiken Industries, Inc. (TC, 1971), acq.: Issue 2 (Poor): Are the interest payments exempt from the withholding tax? Issue 2 (Poor): Should the taxpayer exempt the interest payments from withholding tax? In the first version of issue 2 above, to which interest payments and which withholding tax is the writer referring? The issue does not stand alone since it cannot be precisely understood apart from separately reading the brief�s facts. The extreme brevity leads to ambiguity. In the second version, the question can be interpreted as a moral or judgment issue rather than a legal one. Whether the taxpayer should do (or should not do) something may be a very different issue than the legal question of what the law requires. A legal brief, however, should focus on the latter. Rewriting issue 2 as follows leads to a clearer expression of the precise issue: Issue 2 (Better): Are interest payments exempt from the U.S. 30% withholding tax when paid to an entity established in a tax treaty country for no apparent purpose other than to escape taxation on the interest received?

      Extreme brevity leads to ambiguity. The summary of the issue should be written to avoid opening the question to interpretation as a moral or judgment issue; instead focus on the legal question.