[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Sep 14 10:56:20 PDT 2020
aaron.ballman added inline comments.
================
Comment at: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:216
+ {"long", "l"},
+ {"long long", "ll"},
+ {"unsigned long", "ul"},
----------------
`unsigned long long` -> `ull`
================
Comment at: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:225
+ {"WORD", "w"},
+ {"DWORD", "dw"}};
+ // clang-format on
----------------
`ULONG` -> `ul`
`HANDLE` -> `h`
================
Comment at: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:236
+ PrefixStr = "fn"; // Function Pointer
+ } else if (QT->isPointerType()) {
+ // clang-format off
----------------
I'm not certain how valid it is to look at just the type and decide that it's a null-terminated string. For instance, the following is not an uncommon pattern: `void something(const char *buffer, size_t length);` and it would be a bit strange to change that into `szBuffer` as that would give an indication that the buffer is null terminated. You could look at surrounding code for additional information though, like other parameters in a function declaration. As an aside, this sort of heuristic search may also allow you to change `length` into `cbLength` instead of `nLength` for conventions like the Microsoft one.
However, for local variables, I don't see how you could even come up with a heuristic like you could with parameters, so I'm not certain what the right answer is here.
================
Comment at: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:309
+
+ if (PtrCount > 0) {
+ for (size_t Idx = 0; Idx < PtrCount; Idx++) {
----------------
No need for this `if` statement, the `for` loop won't run anyway if `PtrCount == 0`.
================
Comment at: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:319
+std::string
+IdentifierNamingCheck::getDeclTypeName(const clang::NamedDecl *Decl) const {
+ const ValueDecl *ValDecl = dyn_cast<ValueDecl>(Decl);
----------------
`ND` instead of `Decl`.
The function name doesn't really help me to understand why you'd call this as opposed to getting the type information as a string from the `NamedDecl` itself. I'm a bit worried about maintaining this code as the language evolves -- Clang will get new keywords, and someone will have to remember to come update this code. Could you get away with using `Decl->getType()->getAsString()` and working with that rather than going back to the original source code and trying to parse manually?
================
Comment at: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:320
+IdentifierNamingCheck::getDeclTypeName(const clang::NamedDecl *Decl) const {
+ const ValueDecl *ValDecl = dyn_cast<ValueDecl>(Decl);
+ if (!ValDecl) {
----------------
`const auto *` since the type is spelled out in the initialization.
================
Comment at: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:554
+ case IdentifierNamingCheck::CT_HungarianNotation: {
+ const NamedDecl *ND = dyn_cast<NamedDecl>(InputDecl);
+ const std::string TypePrefix =
----------------
`const auto *` because the type is spelled out in the initialization.
================
Comment at: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h:39
+ std::string getDeclTypeName(const clang::NamedDecl *Decl) const;
void storeOptions(ClangTidyOptions::OptionMap &Opts) override;
----------------
Can you go with `ND` (or something else) instead of `Decl` since that's a type name?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D86671/new/
https://reviews.llvm.org/D86671
More information about the cfe-commits
mailing list