# SAP/styleguides: two ABAP style guides and one link check > SAP/styleguides is a Markdown repository holding SAP's coding style guides, two of them, both for ABAP. Its strength is wording a reviewer can quote, and its limit is that nothing in the repository enforces any of it. **SAP/styleguides** — This repository provides SAP style guides for coding and coding-related topics. - Repository: https://github.com/SAP/styleguides - Stars: 2,035 · Forks: 505 - Language: Markdown - License: NOASSERTION - Published: 2026-10-14 · Updated: 2026-10-14 · Language: en - Canonical page: https://hysenlabs.com/projects/sap-styleguides ## Two style guides, one optional contract SAP/styleguides holds no library and exports no API. It is a Markdown repository with 2 guides, Clean ABAP at clean-abap/CleanABAP.md and ABAP Code Reviews at abap-code-review/ABAPCodeReview.md, and its single repository topic is abap. What a developer takes from the repository is text, not code. The problem it names sits on the first page: a programming language lets you say the same thing in different ways, some more efficient than others and some easier to follow, and the guides try to steer readers toward a balance between those qualities. The audience is people writing ABAP on SAP systems, and a second audience of reviewers who want a written rule to point at instead of personal taste. The contract is deliberately loose. Following the guides is optional, the decision belongs to the team rather than the individual developer, and the README says that latitude extends equally to in-house developers, partners and customers. Its argument is that clean code comes from conviction rather than pressure. No file in the repository turns that preference into a build flag or a blocked pull request, so adoption is something a group agrees to and then maintains by hand. ## The only automation is a Markdown link check Exactly 1 script exists in package.json, and it does not lint prose, code or spelling. It walks the tree, prunes node_modules, collects every .md file except those matching a two-letter suffix pattern, then hands each file to markdown-link-check with the configuration in mlc_config.json. The devDependency behind that job is markdown-link-check at ^3.11.1, and package-lock.json sits at the top level next to it. ```bash find . -path ./node_modules -prune -false -o -name '*.md' ! -name '*_??.md' -print0 | xargs -0 -n1 markdown-link-check -q -c mlc_config.json ``` What a reader sees after running the job is a link verdict, not a style verdict: dead external references and broken relative paths fail, and everything else passes quietly because of the -q flag. Look closely at the exclusion. Files carrying a two-letter suffix are never handed to the checker, so a translated copy holding stale links can sit in the repository without this job noticing. A file named translation_v2.json occupies a top-level slot, yet no translated guide appears beside the 2 guide directories. A .github/ directory is listed at the top level, but no workflow file is documented anywhere in the README, so whether that script runs on pull requests is left unstated. The last push to the main branch was on 2026-04-02. ## package.json points at an index.js that is not there The npm manifest in this repository describes a package that does not exist here. It names the package sap-code-style-guides, pins version 1.0.0, sets private to true, which is the field that blocks any accidental publish, and still declares a main entry of index.js. No such file appears in the top-level listing. ```json "name": "sap-code-style-guides", "version": "1.0.0", "private": true, "main": "index.js" ``` That dangling main entry is the clearest sign that this manifest was never meant to ship a package: it points at a file the repository does not contain. The remaining fields point back at the same place. The repository url is git+https://github.com/SAP/styleguides.git, bugs leads to the issues tracker, homepage leads to the README anchor, and the author field is present and empty. None of it changes how you use the guides, and the only line anyone acts on is the test job. ## Three different answers to one reuse question GitHub could not classify the repository terms and recorded them as Other, the package.json licence field reads ISC, and the README defers to a LICENSE file while linking a Creative Commons summary that asks for credit and a note of changes, so one reuse question has 3 answers. ```json "license": "ISC" ``` The REUSE badge pinned above the README heading, together with .reuse/ and LICENSES/ at the top level, show a machine-readable arrangement in which each file carries its own terms, which is why GitHub's classifier recorded Other instead of guessing at a name. For anyone writing slides, a book or internal documentation, the README gives the practical position in plain words: the content may be used and shared, including inside your own works and even commercially, provided the source is credited and changes are pointed out. That paragraph is what most readers act on, and it disagrees with the ISC string an automated tool pulls out of the manifest, so a developer who reads only package.json sees the wrong family of terms first. No legal reading is offered here. The narrower point is that 2 files in this repository answer the same question and only 1 of them was written for humans. ## Changes go live without a publication date Updates here do not wait for a numbered milestone. Any change to a guide is reviewed and put live immediately, with no special publication step, so a reader who bookmarks abap-code-review/ABAPCodeReview.md gets new content without changing a link and without pinning anything. The README is blunt about the status of the work. These guides are "work in progress" and will never reach a finished state, which the page presents as a property of an agile practice rather than a gap. The people who write them are named as the kind of staff who spend the day coding: developers, architects, quality engineers and consultants, from associates to chief experts, and from S/4HANA work to the ABAP language group. Anyone from within or outside SAP is invited to contribute, and that invitation covers the language as well as the company. Governance lives in files rather than paragraphs. CONTRIBUTING.md carries the mechanics, and the instruction on the front page is short: use GitHub's standard means and agree to the repository terms to contribute directly. CODEOWNERS sits at the top level next to .github/ and GOVERNANCE.md, so routing can be expressed in a file instead of a paragraph. Which guide CODEOWNERS covers, and how long a review takes, are not documented in the README. ## One language covered, and no roadmap past it Coverage stops at ABAP. Only 2 guide directories exist at the top level, both about ABAP, and the repository topic is abap. The front page invites anybody to contribute, but an invitation is not a plan, and no milestone, issue label or per-guide tracking scheme is described for other languages. The same silence shows up where adopters look first. Nothing in the repository maps the guidance onto an existing codebase, so a team inheriting years of ABAP gets prose about what good code looks like and no story about how to introduce it in slices. Nothing grades rules by severity, so there is no way to tell a naming rule from a structural one when a reviewer wants to push back. Nothing records how to disagree with a rule, either, because adoption is optional and the README leaves the call to the team without offering a mechanism for a team to settle that argument. The README does not document a rule identifier scheme either. If your review process wants to cite a specific line of the guide, there is no stable number to cite, only a heading that can move at any commit. ## Rule set to adopt, or narrative to read The repository itself names the other path. For motivation, the underlying principles and the surrounding ecosystem of tools, books and related practices, the README points to a SAP corporate blog post on writing maintainable, readable and testable code. That is a different approach rather than a second copy of the same rules: the blog carries the reasoning, while the 2 guides say what to type. The difference shows up in what you can do with each. A guide gives you a sentence you can paste into a review comment and expect a team to follow. A blog post gives you an argument to win an internal discussion, and nothing you can enforce afterwards. Choosing the guide path costs you adoption work by hand, since no linter, severity table or exceptions file exists in this repository and the single automated job checks links. Choosing the narrative path costs you specificity, because principles arrive without a rule list to apply. For an SAP team, that usually means reading the blog once and copying the specific guide paragraphs that survive your own argument about them. ## Conclusion Adopt these 2 pages if your team writes ABAP and wants a shared review vocabulary you can paste into a comment today. Skip them if you need enforcement, because the repository ships a link checker and nothing that reads ABAP, so every rule stays a conversation. Read the reuse terms before the ISC string in the manifest, read clean-abap/CleanABAP.md and abap-code-review/ABAPCodeReview.md end to end, and expect no numbered rule to cite when a review turns into an argument. Both guides are Markdown prose, and neither is wired into a build that can fail. ## FAQ ### Which languages does SAP/styleguides cover? ABAP only. The repository lists 2 guides, clean-abap/CleanABAP.md and abap-code-review/ABAPCodeReview.md, and its single topic tag is abap. The README invites contributions from outside SAP but names no other language. ### How do I run the checks in SAP/styleguides? The test job in package.json runs markdown-link-check against every .md file using mlc_config.json, and it skips files matching a two-letter suffix pattern. The only automated check is that job, and no workflow file is documented in the README. ### Is following the SAP style guides mandatory? No. The README says following the guides is optional and that the choice belongs to your team, and that this applies equally to in-house developers, partners and customers. ### Can I reuse SAP style guide content in my own slides or book? The README says you can freely use and share the content, including in your own works such as presentations or books, even commercially, as long as you credit the source and point out your changes. ### How do I contribute to SAP/styleguides? CONTRIBUTING.md describes the process, and the README puts it in one line: use GitHub's standard means to add to the repository, and agree to the repository terms to contribute directly. CODEOWNERS governs routing. ## Sources - [Issues](https://github.com/SAP/styleguides/issues) - [README](https://github.com/SAP/styleguides/blob/main/README.md) - [Releases](https://github.com/SAP/styleguides/releases) - [SAP/styleguides on GitHub](https://github.com/SAP/styleguides) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sap-styleguides