Coding standards

(Cross posted from http://drupal.org/node/2099351 because Angie said I could/should. This isn't a core issue, but it's an upgrade to D8 issue. We are talking about tackling automatic code upgrades.)

If the community agrees with the plan. It will be a few weeks or a more before I'm ready to ask people to write upgrades. But before we get there, in general, does this sound like a good plan or not? Please provide feedback on the d.o issue http://drupal.org/node/2099351.

Summary:

A module, by definition, adds a feature to a Drupal installation. A well written module often provides administrative touches such as the ability to 'hide' the feature from certain user roles or because of a particular site configuration.
This is all well and good, but a problem can arise for the administrator when testing, if the module supplying the feature fails to supply some kind of visual feedback to indicate when it is in 'feature hiding' mode.

There are a handful of modules that set extra cookies to accomplish various things outside of the session. Some of them are used only on the client side and the server never needs to see them. Some of them are actually used on the server side. See:
https://wiki.fourkitchens.com/display/PF/Modules+that+break+caching,+and...

Problem/Motivation

There are externally-developed files, such as misc/jquery.js and module/system/system.tar.inc that should not be updated to meet Drupal coding standards.

<

dl>

There is frustration among new developers about how to make issues and patches that cause a minimum of disruption and a maximum of ease for reviewers/committers.

So we need to make a page explaining this. Suggested outline is on the above comment, and suggested place to put it is either:
http://drupal.org/patch
or
http://drupal.org/patch/review

Posted by sun on October 1, 2011 at 8:09pm:

Problem

• Uncertainty about when or how to apply coding standards across Drupal core versions and core vs. contrib code.

Goal

• Clarify the scope of coding standards with regard to:

  1. major versions of core
  2. core vs. contrib code

• Explicitly specify/state which particular coding standards have been different for earlier versions.

As we move to converting low level system in core to classes, we need to define a convention for doing so.

Please chime in on the discussion at http://drupal.org/node/1239644.

I'm referencing the Drupal Markup Style Guide g.d.o wiki in the Definitive Guide to Drupal 7 and it hasn't been updated in a couple years so i wanted to give all interested parties, especially HTML5 folk, foreknowledge to update it (or link it to a d.o equivalent?).

Advice is sound and it's the most comprehensive take i've seen from a module developer's perspective, so that's why i'm providing the link: http://groups.drupal.org/node/6355

Apparently, Git doesn't like commit messages that start with a pound sign, which leads us to define a new standard format for commit messages.

Hey all -

DrupalCon Chicago's Core Conversation proposals need to be in by next Friday. Jennifer (jhodgdon) and I have been pondering whether and what might make a good topic or two to pitch.

Please post with ideas and whether you'd be interested in attending a docs focused session, it'll help us gear our proposal towards something everyone will be interested in!

Thanks!

Code review of existing contributed modules is frequently cited as a means to improving the quality of existing contributed modules. However, the task of performing a code review falls somewhere between documentation, writing and reviewing patches, reviewing CVS applications, and creating new modules.

This is a proposal to elevate the visibility of module review, and make it easier for newcomers to perform module reviews.

Modules are grouped on the module administration page (admin/modules in Drupal 7) by package, which is defined, optionally, in our module's .info file. Package, then, is the most visible way in which modules are categorized. This wiki page documents package names chosen by module maintainers, please edit it!

A ping in #drupal-docs earlier has brought to my attention that the Docs style guide only applies to handbook and not explicitly to interface text in Drupal core/contrib.

I'd think it should apply so we get consistent text and grammar formatting Drupal-wide, but didn't want to make such a sweeping declaration without some consensus from the community at large.

We don't have a standard doc header for implementations of themeable functions like THEME_process_HOOK and theme_breadcrumb.

my suggestion:

or

A new issue: http://drupal.org/node/716496

There is a discussion there about how to standardize the doc header for default theme implementation functions, such as theme_table(). Please respond there if you are interested. Thanks!

There's a discussion going on about standards for documenting classes and interfaces in the Drupal API -- please comment on the issue (and NOT here) if interested:
http://drupal.org/node/718596

I'd strongly recommend to add a directive in coding standards to ban common (global) variable names for temporary tasks.

This is a very important security issue as it can lead to certain accidental variable overwrites such as:

In context of a $node some code tries to load assigned user object and does $user = user_load($node->nid);
While this feels pretty OK for the first second one single global $user before this line will lead to a user context switch and thus permission takeover.
This is a very common mistake i've seen many times - and which happens too soon...

A experimental document on an architectural standard.

As you know if you've fiddled with PHP's error_reporting setting, Drupal 7 is not yet E_STRICT compliant. E_STRICT compliance is a good idea for forward compatibility (PHP 5.3 and 6.0) and also helpful for servers that already log E_STRICT errors.

THIS WIKI PAGE IS A WORK IN PROGRESS

In helping with LA Drupal's D7 Code+Test Sprint event, I noticed there's some easy points that help newbies feel progressive. There are many ways to help at a Code+Test sprint, and here are the ways that helped us in Los Angeles.

• Make sure you have a Drupal.org account, with "Contributor links" turned on in your profile. This will expose a sidebar block linking to areas of interest for contributors. For example: "Patches to review (D7)" is what most people click on to find patches needing review.