style: copyedit, remove clauses that duplicate PEP8

develop/style.rst

@@ -3,63 +3,31 @@ Style Guidelines
 ****************
 
 **Note:** Code not following these style guidelines fastidiously is likely
-(*very* likely) not to be accepted into the Supybot core.
+not to be accepted into the Limnoria core.
 
 * Read :pep:`8` (Guido's Style Guide) and know that we use almost all the
   same style guidelines.
-
-* Maximum line length is 79 characters.  78 is a safer bet, though.
-  This is **NON-NEGOTIABLE**.  Your code will not be accepted while you are
-  violating this guidline.
-
-* Identation is 4 spaces per level.  No tabs.  This also is
-  **NON-NEGOTIABLE**.  Your code, again, will *never* be accepted while you
-  have literal tabs in it.
-
-* Single quotes are used for all string literals that aren't docstrings.
-  They're just easier to type.
-
-* Triple double quotes (``"""``) are always used for docstrings.
+  - We use a maximum of 79 characters per line and 4 spaces per indentation level
+  - Exception: method and function names generally use camelCase for consistency
+    with existing code.
 
 * Raw strings (``r''`` or ``r""``) should be used for regular expressions.
 
-* Spaces go around all operators (except around ``=`` in default arguments to
-  functions) and after all commas (unless doing so keeps a line within the 79
-  character limit).
-
-* Functions calls should look like ``foo(bar(baz(x), y))``.  They should
-  not look like ``foo (bar (baz (x), y))``, or like ``foo(bar(baz(x), y) )``
-  or like anything else.  I hate extraneous spaces.
-
-* Class names are StudlyCaps.  Method and function names are camelCaps
-  (StudlyCaps with an initial lowercase letter).  If variable and attribute
-  names can maintain readability without being camelCaps, then they should be
-  entirely in lowercase, otherwise they should also use camelCaps.  Plugin
-  names are StudlyCaps.
-
-* Imports should always happen at the top of the module, one import per line
-  (so if imports need to be added or removed later, it can be done easily).
-
 * Unless absolutely required by some external force, imports should be ordered
   by the string length of the module imported.  I just think it looks
   prettier.
 
-* A blank line should be between all consecutive method declarations in a
-  class definition.  Two blank lines should be between all consecutive class
-  definitions in a file.  Comments are even better than blank lines for
-  separating classes.
-
 * Database filenames should generally begin with the name of the plugin and
   the extension should be 'db'.  plugins.DBHandler does this already.
 
 * Whenever creating a file descriptor or socket, keep a reference around and
   be sure to close it.  There should be no code like this::
 
-    s = urllib2.urlopen('url').read()
+    s = urllib.request.urlopen('url').read()
 
   Instead, do this::
 
-    fd = urllib2.urlopen('url')
+    fd = urllib.request.urlopen('url')
     try:
         s = fd.read()
     finally:
@@ -67,9 +35,10 @@ Style Guidelines
 
   This is to be sure the bot doesn't leak file descriptors.
 
-* All plugin files should include a docstring decsribing what the plugin does.
+* All plugin files should include a docstring describing what the plugin does.
   This docstring will be returned when the user is configuring the plugin.
-  All plugin classes should also include a docstring describing how to do
+
+* All plugin classes should also include a docstring describing how to do
   things with the plugin; this docstring will be returned when the user
   requests help on a plugin name.
 
@@ -79,27 +48,20 @@ Style Guidelines
   by the ``syntax`` command, and the longer description is used by the
   ``help`` command.
 
-* Whenever joining more than two strings, use string interpolation, not
-  addition::
+* Whenever joining more than two strings, use f-strings or string
+  interpolation, not addition::
 
     s = x + y + z # Bad.
     s = '%s%s%s' % (x, y, z) # Good.
-    s = ''.join([x, y, z]) # Best, but not as general.
-
-  This has to do with efficiency; the intermediate string x+y is made (and
-  thus copied) before x+y+z is made, so it's less efficient.  People who use
-  string concatenation in a for loop will be swiftly kicked in the head.
+    s = ''.join([x, y, z]) # Better, but not as general.
+    s = f'{x}{y}{z}' # Best.
 
 * When writing strings that have formatting characters in them, don't use
-  anything but ``%s`` unless you absolutely must.  In particular, ``%d`` should never
-  be used, it's less general than ``%s`` and serves no useful purpose.  If you got
-  the ``%d`` wrong, you'll get an exception that says, "foo instance can't be
-  converted to an integer." But if you use ``%s``, you'll get to see your nice
-  little foo instance, if it doesn't convert to a string cleanly, and if it
-  does convert cleanly, you'll get to see what you expect to see.  Basically,
-  ``%d`` just sucks.
+  anything but ``%s`` unless you absolutely must.  Avoid ``%d`` in particular
+  because it's not as general and is likely to throw type errors if you make a
+  mistake.
 
-* As a corrolary to the above, note that sometimes ``%f`` is used, but on when
+* As a corollary to the above, note that sometimes ``%f`` is used, but on when
   floats need to be formatted, e.g., ``%.2f``.
 
 * Use the log module to its fullest; when you need to print some values to
@@ -129,7 +91,7 @@ Style Guidelines
 
   * WARNING:  Appropriate to tell a user when we're doing something that they
     really ought to pay attention to.  Users should see WARNING and think,
-    "Hmm, should I tell the Supybot developers about this?"  Later, they should
+    "Hmm, should I tell the Limnoria developers about this?"  Later, they should
     decide not to, but it should give the user a moment to pause and think
     about what's actually happening with their bot.
 
@@ -139,8 +101,8 @@ Style Guidelines
     be errors.
 
   * CRITICAL: Not really appropriate.  I can think of no absolutely critical
-    issue yet encountered in Supybot; the only possible thing I can imagine is
-    to notify the user that the partition on which Supybot is running has
+    issue yet encountered in Limnoria; the only possible thing I can imagine is
+    to notify the user that the partition on which Limnoria is running has
     filled up.  That would be a CRITICAL condition, but it would also be hard
     to log :)
 
@@ -151,10 +113,6 @@ Style Guidelines
   plugins are adequately documented; PluginTestCase checks that every command
   has documentation)
 
-* All uses of eval() that expect to get integrated in Supybot must be approved
-  by jemfinch, no exceptions.  Chances are, it won't be accepted.  Have you
-  looked at utils.safeEval?
-
 * SQL table names should be all-lowercase and include underscores to separate
   words.  This is because SQL itself is case-insensitive.  This doesn't
   change, however the fact that variable/member names should be camel case.