coreboot-kgpe-d16/.checkpatch.conf

39 lines
1.0 KiB
Plaintext
Raw Normal View History

# Not Linux, so don't expect a Linux tree.
--no-tree
# Ignore aspects we don't follow here.
--ignore C99_COMMENTS
--ignore GLOBAL_INITIALISERS
--ignore COMPARISON_TO_NULL
--ignore INITIALISED_STATIC
--ignore LINE_SPACING
--ignore NEW_TYPEDEFS
--ignore SPLIT_STRING
--ignore BLOCK_COMMENT_STYLE
--ignore AVOID_EXTERNS
--ignore VOLATILE
--ignore CONFIG_DESCRIPTION
--ignore MISSING_SPACE
--ignore CORRUPTED_PATCH
--ignore SPDX_LICENSE_TAG
--ignore UNDOCUMENTED_DT_STRING
--ignore PRINTK_WITHOUT_KERN_LEVEL
lint: checkpatch: Ignore ASSIGN_IN_IF and UNNECESSARY_ELSE errors This patch disables checkpatch warnings about two style constructs that are not illegal in coreboot style and can in my opinion be useful in certain situations. The first is an assignment in if conditions like this: if ((ret = func())) return ret; This can save a line compared to the alternative construct which may help readability, especially in functions that need to do a lot of these. More importantly, the while-equivalent of this construct is not forbidden (and a lot more useful, because certain things become very complicated to write without it), and it seems weird to forbid one but not the other. We already have GCC warnings that enforce an extra set of parenthesis to highlight that this is an assignment instead of a comparison, so the risk of typos or confusion between those two is already mitigated anyway. The second is the use of `else` after return like this: if (CONFIG(TYPE_A)) return response_for_type_a; else return response_for_type_b; While the else is redundant in this case, it serves to highlight the symmetry and equivalence in importance of the two paths. There are certainly other situations where the construct of if (something_went_wrong) return error; if (something_else_went_wrong) return other_error; if (...) is more useful, but this usually suggests an "either abort here or continue on the main path" style flow, whereas the code with `else` is more suitable to highlight an "either one or the other" flow with two equal-weighted options. I think the programmer should pick which style best represents the intentions of their code in these cases, and don't understand why one of the two should be categorically forbidden. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I130598057c1800277a129ae6b927e961d6e26e42 Reviewed-on: https://review.coreboot.org/c/coreboot/+/51551 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-03-16 23:59:01 +01:00
--ignore ASSIGN_IN_IF
--ignore UNNECESSARY_ELSE
--ignore GERRIT_CHANGE_ID
# FILE_PATH_CHANGES seems to not be working correctly. It will
# choke on added / deleted files even if the MAINTAINERS file
# is touched.
--ignore FILE_PATH_CHANGES
# This one has a linux path hard coded, so it would choke on
# some commits unnecessarily.
--ignore EXECUTE_PERMISSIONS
# Exclude vendorcode directories that don't follow coreboot's coding style.
--exclude src/vendorcode/amd
--exclude src/vendorcode/cavium
--exclude src/vendorcode/intel
--exclude src/vendorcode/mediatek