| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A comment is read without the change that introduced it, so one
that records the author's reasoning -- what was tried, rejected,
or done before -- is confusing once the code it contrasts with is
gone. AI coding agents produce these readily, so let's document
that this is undesirable, so both humans and AI agents don't
do it as readily.
Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Neil Horman <[email protected]>
Merge-date: Fri Oct 2 08:06:12 2026
Merged-from: https://github.com/openssl/openssl/pull/32779
|
| |
|
|
|
|
|
|
|
|
| |
Specifically bring them closer to the suggested naming conventions
and make them clang-format compliant.
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Milan Broz <[email protected]>
MergeDate: Fri Jul 10 15:37:20 2026
(Merged from https://github.com/openssl/openssl/pull/29295)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To be at the prototype site in the internal header file.
The major reason *Why* we would like to have Doxygen style comments
describing what internals do is so that they work with modern IDE's
since most common ones support them.
It's wonderful to be looking at an internal function, thinking "wtf is this",
and be able to hover over it and - boink - up comes the docs. This
typically only works (or works better) when the Doxygen comment is
at the prototype site, not if it is at the implementation site.
This also reinforces the requirement that "yes you do this for shared
functions but you don't need to for statics".
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Milan Broz <[email protected]>
MergeDate: Fri Jul 10 15:37:18 2026
(Merged from https://github.com/openssl/openssl/pull/29295)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So this repatriates DOCUMENTATION.MD from the web page to the
code base, and links both STYLE.MD and DOCUMENTATION.MD from
CONTRIBUTING.MD
It does a large rototilling of STYLE.MD to address many of the
outstanding concerns noted when I started this before clang-format
last year, and brings us roughly in line with the things that are
addressed in similar style guides for other projects.
Most of the changed or updated reccomendations reflect what we
currently have been doing, or have expressed as a desire to
move to in the future.
Most larger "OpenSSL-isms" I've tried to explicitly call out
to make this a more cohesive and useful guide for a new contributor
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Milan Broz <[email protected]>
MergeDate: Fri Jul 10 15:37:16 2026
(Merged from https://github.com/openssl/openssl/pull/29295)
|
|
|
This is effectively, the current coding style policy web page
changed to accomodate clang-format. This is more or less the
same file I have had in the various clang-format sample PR's since
September.
It does include an additional sections on Integers and on
Return Values that are not in the original coding style
policy
It is changed from the September version in that it does not
have mention of keeping include files self contained. I believe
that is achievable and desirable, but I think should be done
as a separate change from this.
There were a number of issues brought up in discussion of this
file in the clang-format PR's. I recorded those in 818, 819,
820, 821, 822, 823, 824, 825, and 826, which we can
link in there to the appropriate section of the document.
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Milan Broz <[email protected]>
MergeDate: Fri Jul 10 15:37:13 2026
(Merged from https://github.com/openssl/openssl/pull/29295)
|
