unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Kangas <stefankangas@gmail.com>,
	Boruch Baum <boruch_baum@gmx.com>,
	 Emacs-Devel List <emacs-devel@gnu.org>
Subject: RE: adding to emacs coding standard / formatting
Date: Mon, 19 Oct 2020 08:37:50 -0700 (PDT)	[thread overview]
Message-ID: <4373c134-bdfe-4ad6-bee2-a98807aacd60@default> (raw)
In-Reply-To: <CADwFkmn8U-TzfRRxfOgRSveYU=-r5wr+WN9xDFRTETrTwUn6Bw@mail.gmail.com>

> FWIW, I wouldn't like to see this added to our coding standards at a
> language level.  I find it overly bureaucratic.  Files should follow a
> standard that makes sense to what its trying to present.
> 
> Also, third-party package developers should have some room to maintain
> their own standards.

FWIW, I agree.

I personally do group things, and label the groupings,
when it makes sense.

But there are different ways to group/organize things,
and, as always, local consistency is more important
than global consistency.  (Who knows best which
organization makes most sense locally?  The author.)

For example, it may typically make sense to put
defcustoms together - I generally do that, in a
section labeled to that effect.

But sometimes it makes sense to put a particular
defcustom together with some other bits of code
directly related to it, where that group of stuff is
not so tightly related to the other parts of the file.
For example, when some subfeature is involved, guarded
by some condition, e.g., (when (featurep 'foo) ...).

Our coding conventions are just guidelines (except
for inclusion in Emacs, where they're considered more
strictly).  But they should be important, not
gratuitous.  In general, users should be the judges of
how to organize and present their work.  Guidelines
should be a help, not a hindrance.

[BTW, there is plenty of code that's part of Emacs
that doesn't strictly follow our guidelines - max
line length, for instance.]



  reply	other threads:[~2020-10-19 15:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-19  3:10 adding to emacs coding standard / formatting Boruch Baum
2020-10-19  9:28 ` Stefan Kangas
2020-10-19 15:37   ` Drew Adams [this message]
2020-10-19 14:24 ` Stefan Monnier
2020-10-19 14:32 ` Eli Zaretskii
2020-10-19 19:59   ` Boruch Baum
2020-10-19 20:07     ` Drew Adams
2020-10-21  4:37       ` Richard Stallman
2020-10-21 14:46         ` Drew Adams
2020-10-20  5:11 ` Richard Stallman
2020-10-20  5:11 ` Richard Stallman
2020-10-20  5:55   ` Boruch Baum
2020-10-20  8:32     ` Eli Zaretskii
2020-10-20  9:30     ` Jean Louis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4373c134-bdfe-4ad6-bee2-a98807aacd60@default \
    --to=drew.adams@oracle.com \
    --cc=boruch_baum@gmx.com \
    --cc=emacs-devel@gnu.org \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).