[guide] Non-code issues: keep them out of your code files.

[mk-pmb]

Summary of #1640. I extrapolated the reasoning to other transport layer packaging, hope it's the right conclusion.

[mk-pmb]

rebased on current master.

[ljharb]

This section seems like it's full of "don't"s, without any "do's".

Can you be more specific about what kinds of things this advice would avoid, and what better alternatives would look like?

[mk-pmb]

For clearer dos and don'ts about the BOM, we could use code blocks that contain just explanatory comments. Would at least keep the visual style consistent:

/* <- bad:  Invisible BOM at start of code file, meant to
            fix your editor's charset.
      good: Set the charset in your editor config.
            If you need per-project config and your editor
            doesn't support it, get a better one.           */

/* <- bad:  Invisible BOM at start of code file, meant to
            fix some browser's charset guessing.
      good: Use your webserver or some part of your toolchain
            to add the charset info.                        */

[mk-pmb]

Draft of example for omitting potential UMD wrappers:

// bad: Bloat project code with AMD/UMD export.
(function unifiedExport(e) {
  var d = ((typeof define === 'function') && define),
    m = ((typeof module === 'object') && module);
  if (d && d.amd) { d(function () { return e; }); }
  if (m && m.exports) { m.exports = e; }
}(api));

// good: 
// Just omit it. Use your toolchain to add compatibility
// mechanisms only in the dist version.

Edit: Not a good example though, since an export statement would prevent old browsers that need AMD/UMD from parsing the script at all. Overlaps with rule 10.1.