Coding Standard Framework

Draft Standard

The information found on this page is a work in progress. As feedback is collected, there will likely be revisions.

Nothing in the draft should be taken as a requirement or directive at this point in time.

At Northwestern, lots of teams are using lots of different programming languages, tools, frameworks, and libraries to build a diverse set of applications.

The SDCC cannot provide specific guidance for every technology. Instead, we provide common standards that are broadly applicable, a framework for building a tech-stack-specific coding standard, and a repository of “known good” coding standards.

Goals

The purpose of these coding standards is to provide for a common set of “core functionality” and commonality between IT@NU applications. This is useful for a few reasons:

1. Consistent tools/checks across IT@NU, so developers working cross-project can safely & confidently contribute.
2. Consistent code formatting in a project, so diffs between versions are legible for code review.
3. Consistent developer documentation in each project, so developers can “drop in” from different units and know how to get set up & collaborate on a project.
4. Mandated tools/checks for certain security- & compliance-related items, like web accessibility.
5. Consistency in logging some types of events & dependency management, so the Information Security office can mount an effective response during an incident.

Scope

The coding standards are oriented towards custom development in traditional programming languages: building your own application with something like PHP, Java, .NET, or Python. When developing custom software, the general coding standard and applicable stack-specific standards SHOULD be followed.

These standards are not applicable to proprietary vendor ecosystems. None of this will make sense for a low-code tool like Power Automate, for example. But, depending on usage, some of this could be applicable to a programmable platform like Salesforce. Developers SHOULD consider what standards, if any, are applicable to vendor & SaaS products.

Application Types

Broadly, the standards consider three main types of applications:

• Web: static or dynamic sites accessed through a browser.
• Libraries: reusable components meant for other developers.
• Data Integrations: standalone backend processes that move or transform data, without directly offering an end-user experience.

These MAY have different coding standards. For example: web applications will always need to be WCAG 2.1 AA compliant, but this standard is not applicable to a library.

Contributing

Standards for specific tech stacks should be developed and maintained by team(s) actively using those languages, frameworks, and tools. Any unit is welcome to contribute new stack standards or suggest changes to an existing document.

These are shared standards for all developers at Northwestern. Other units may be using the same technologies differently. In these cases, differences should be discussed among users and a consensus formed. There may be a “right” answer that groups can agree on, or there may be multiple “right” answers that the standard can provide guidance for selecting.

Tech stack documents SHOULD align to the structure of the General Coding Standards document. They can omit sections if they are not applicable, and add sections where additional clarity is useful. But, for ease of translating the general standards into more specific recommendations, strive to repeat the same headings.