I'm trying to customize checkstyle checkers.
For example,
I want the MagicNumber checker to detect only constant 0 for all code patterns except for-statement.
'for statement' is allowed to use -1, 0 and 1.
Could you let me know how I can customize this checker or other checkers?
Most Checkstyle checks can be customized in some way. The exact options (called properties) available vary by check. Each check documents its properties.
So, for instance, MagicNumber has these options. Unfortunately, the properties you are looking for (to allow magic numbers in for loops; to detect only certain individual numbers) are not available.
In such a case, you must write your own check, potentially as a subclass of the check you want to modify.
My personal recommendation is to use the MagicNumber check as-is, and fix all the magic numbers, especially those in for loops. But that's just me. ;-)
Related
The question is : what are the NET USE possible outputs?
You can drown yourself with websites explaining how to use NET USE command, but not a single one about what is coming out of it.
In my case I'm interested in the various error messages, and the interaction with the Powershell automatic variable $LASTEXITCODE. I want to handle its output correctly but I don't know what can even happen (and no, I won't use New-PSDrive).
Does someone knows the what or where I can find the information ?
Thanks
You can use the example in https://www.compatdb.org/forums/topic/20487-net-use-return-code/ to obtain a list of the numerical codes for your evaluation.
If you want to dig deeper take you need to download the Win32 SDK and go through the definitions in the header files (see https://learn.microsoft.com/en-us/windows/win32/api/winnetwk/ns-winnetwk-netresourcea etc).
I was looking for get and put to be available in ISOIO mode but they are not. What is enabled with ISOIO?
The details are undocumented, it seems like it mostly a subset of {$mode iso} for reading/writing files, that reroutes RTL handlers for reset/read/write to the ones for $mode ISO, and limits the types allowed for read/write in text mode.
It also enables look ahead with filetype^. (which is probably the reason why there are _ISO specific handlers in the first place, together with the ISO form of the RESET() statement) and variables
of ISO filetypes seem to be initialized. (under some circumstances)
I don't see enabling of get/put, but I'm no compiler crack, so I might have missed that. You can test that yourself. (whoops on rereading your post, you already did).
So I think the answer is primarily lookahead with the ^ operator.
**added later response from Pascaldragon **
A Pascal developer more into dialectal items finally reacted, which I quote here verbatim:
Put and Get are not part of modeswitch ISOIO, because they're not intrinsics and are instead provided by the ISO7185 unit which is only used for modeswitch ISO. As that unit also contains functionality that's not covered by the ISOIO modeswitch (some types, Round functions) it's not used for that modeswitch, but only together with the mode.
So basically the implementation is a library thing, and can't easily be decoupled from the other library based ISO stuff.
I have a few related questions about pragmas. What got me started on this line of questions was trying to determine whether it's possible to disable some warnings without going all the way to no worries (I'd still like to worry, at least a little bit!). And I'm still interested in the answer to that specific question.
But thinking about that issue made me realize that I don't really understand how pragmas work. It's clear that at least some pragmas take arguments (e.g., use isms<Perl5>). But they don't seem to be functions. Where do they fit into the overall MOP? Are they sort of like Traits? Or packages? Is there any way to introspect over them? See what pragmas are currently in effect?
Are pragmas built into the language, or are they something that users can add? When writing a library, I'd love to have some errors/warnings that users can optionally disable with a pragma – is that possible, or are they restricted to use in the compiler? If I can create my pragmas, is there a practical difference between setting something with a pragma versus with a dynamic variable, aside from the cleaner look of a pragma? For that matter, how do we decide what language features should be set with a pragma versus a variable (e.g., why is $*TOLERANCE not a pragma)?
Basically, I'd be interested in any info about pragmas that you could offer or point me towards – though my specific question is still whether I can selectively turn off certain warnings.
Currently, pragmas are hard-coded in the handling of the use statement. They usually either set some flag in a hash that is associated with the lexical scope of the moment, or change the setting of a dynamic variable in the grammar.
Since use is a compile time construct, you can only use compile time constructs to get at them (currently) (so you'd need BEGIN if it is not part of a use).
I have been in favour of decoupling use from pragma's in the past, as I see them as mostly a holdover from the Perl roots of Raku.
All of this will be changed in the RakuAST branch. I'm not sure what Jonathan Worthington has in mind regarding pragmas in the RakuAST context. For one thing, I think we should be able to "export" a pragma to the scope of a use statement.
I've inherited a very large Flex project which uses data binding throughout and in many places it is unclear why (for what purpose) it is being used. I'd like to simplify the code and remove unnecessary data bindings but I don't know how to determine if a particular binding is being used.
Is there a way I can easily determine if any other classes are using a particular var declared as bindable?
The simplest solution (though crude) is to delete the [Bindable] annotation and then look at the warnings from the compiler.
Alternatively, you could rename the variable or make it private and look for compile errors.
Both of these approaches suffer from only applying to one variable at a time. Unfortunately, I'm not aware of any way to generate a report for all bindings.
Assume I have /foo/X.a and /foo/X.dylib, and LDFLAGS=-L/foo. What will AC_CHECK_LIB do? Is .dylib guaranteed to take precedence over .a? Vice versa? Random?
Assume I have /foo/Y.a and /bar/Y.a, and LDFLAGS=-L/foo:/bar? What will happen then?
Is there some way to manually establish precedence?
This problem is not addressed by autoconf. In the case that you have both /foo/X.a and /foo/X.dylib, the configure script will simply attempt to link with libX and will do whatever your toolchain does. If your linker uses X.a, then the configure script will do its tests using X.a. If your linker uses X.dylib, then the configure script will use that. The way to establish precedence will therefore depend on your toolchain (e.g. perhaps you can add -Bstatic to LDFLAGS).
Is there some way to manually establish precedence?
You are manually establishing precedence of library search by using the -L option.
Also what if I have /foo/Y.a and /bar/Y.a, and LDFLAGS=-L/foo:/bar
What will happen then?
It will look in the directory /foo:/bar before the default library paths. It's not clear from your question if Y.a is actually supposed to be linked to anything.
What will AC_CHECK_LIB do? Is .dylib guaranteed to take precedence over .a? Vice versa? Random?
It won't be random, but will be influenced by other options given to configure (e.g. LDFLAGS, --disable-shared, etc.). All AC_CHECK_LIB does is plop in the name of the selected function into a main function (with appropriate libraries added) and see if it links.