Continuous Release · Open Source · Grassroots Project · Optional · Ecosystem
This repository provides SAP's style guides for coding.
Programming languages enable us to say the same thing in different ways. While all of them may be correct, some may be more efficient, easier to understand, and more robust than others.
Our style guides want to show up differences and guide you towards code that has a healthy balance between all of these qualities.
These guides are updated continuously, meaning any change is reviewed and immediately put "live", without special publication versions.
As programming languages and our understanding of them evolve, we believe that these guides are "work in progress" and will probably never see a status "finished"; as agile developers, we welcome this.
This repository is open source, meaning it is written by a loose community of interested persons, and anybody from within and without SAP is invited to contribute.
LICENSE describes how you may use this material. Creative Commons' summary may be easier to understand for non-jurists. In short, you can freely use and share this repository's content. You can also use it in own works, such as presentations or books, even commercially, as long as you give credit to this source, and point out your changes. Detailed information including third-party components and their licensing/copyright information is available via the REUSE tool.
CONTRIBUTING describes how you can contribute. In short, you can use GitHub's standard means to add to this repository, and you have to agree to our license to contribute directly.
We believe that clean code should be discussed freely and openly.
These guides are grassroots projects, meaning they were started, and are still driven, by programmers who spend their day coding, and want to get better at it.
We are developers, architects, quality engineers, and consultants, from associates to chief experts, from language creators to tool developers, from S/4HANA to the ABAP language group. We respect all roles, ranks, and units, and welcome any suggestions and improvements.
Following these style guides is optional, meaning you - or more precisely: your team - can choose whether you want to adhere to it. This applies equally to in-house developers, partners, and customers.
We believe that clean code comes from conviction, not from pressure.
If you want to learn more about the motivation, the underlying principles and the forming ecosystem of tools, books and related practices around the style guide, you can follow the blog on Clean Code: Writing maintainable, readable and testable code.