When naming command-line flags, and flags in general what's the best practice regarding flags that disable things?
Should I be going for something like:
--disable-thinging
or
--no-thinging
I'd make it --thinging 0 and --thinging 1 (or with false/true). Just like a boolean variable. You can document the default value.
Related
In Rust, you can use the black_box function to force the compiler to
assume that the function's argument is used (forcing it not to optimize away code that generates that value)
not be able to inspect how its return value is produced (preventing it from doing constant-folding and other such optimizations).
Is there a similar facility in Go (to accomplish either task)?
Is there a similar facility in Go (to accomplish either task)?
No.
If you want to use a result: Assign to an exported global.
I believe runtime.KeepAlive is recommended, as per the following Github issue. Unfortunately, it's unclear whether anything exists for function arguments, or whether KeepAlive is even guaranteed to work.
https://github.com/golang/go/issues/27400
As stated in the Microsoft docs, the parameter Flags of the LdrRegisterDllNotification must be zero, but no further explanation is provided. What's the purpose of defining this parameter at all if the only accepted value is zero? What happens if a non-zero value is passed instead?
Parameters where the documentation tells you to pass zero has two possible reasons:
The parameter is unused in all existing Windows versions but might be used for something in the future. The developer might have envisioned extra features but they did not have time to implement them etc.
The parameter is used to pass undocumented information/flags that triggers some private functionality inside the function. Windows 95 for example supports undocumented flags in its *Alloc functions that causes them to allocate shared memory visible to all processes.
Either way, the best practice is to just follow the documentation and pass zero.
I like to name my types using Pascal case - starting with an upper case letter. In Go this implies the name is exported.
To avoid export, I've started to prefix the type name with undercsore instead of lower-casing the first letter.
E.g: Instead of
type Column struct{}, I use type _Column struct{} to avoid export.
I haven't seen this naming scheme used, but neither found any reason not to use it.
Since golint accepts it without complaint, I guess this is OK?
Conclusion: Based on answers and comments I've decided to stay with lower-cased type names.
I'd suggest using column in preference to _Column, on the basis that the style used by the standard libraries follow that naming convention.
This is not explicit in the Names section of the style guide, but based on the fact that underscores are generally discouraged, I'd say that using _Column is, at best, not idiomatic.
"I like to" and go don't super mix.
There are idiomatic bits and tooling enforced bits.
The community sticking to the standards makes for codebases that can be reasonably easy to read and comprehend by others.
I find this to be one of the best attributes of go.
Sure, channels and goroutines are nice.
Easily being able to read a codebase is often much more valuable.
I read that it's a good convention to name functions that return a bool like IsChecksumCorrect(Packet), but I also read that it's a good convention to name boolean variables like IsAvailable = True
But the two rules are incompatible: I can't write:
IsChecksumCorrect = IsChecksumCorrect(Packet)
So what's the best way to name vars that store boolean values returned by such functions?
PS: Extra points if you can think of a way that doesn't depend on changing the case (some languages--like Delphi--are case-insensitive).
First of all, there can be difficulties only with functions that don't require arguments, in your example instead the variable should just be called IsPacketChecksumCorrect.
Even with functions with no arguments I think you would only have problems if you were just caching the result of the function, for performance's sake, and you could safely replace all instances of the variables with calls to the function if it weren't for the performance. In all other cases I think that you could always come up with a more specific name for the variable.
If you were indeed just caching, why not just call the variable Functionname_cache? It seems quite clear to me.
If you needed to use a lot this "technique" in your project and _cache seemed too long or you did not like it you could well settle on a convention of your own; as long as you are consistent you can adopt whatever works best for you, people new to the project just need to be explained the convention once and they will easily recognize it ever after.
By the way, there are various opinions on the conventions for the naming of booleans. Personally I prefer to put the subject first, which makes the Ifs more readable, e.g. ChecksumIsCorrect, ChecksumCorrect or ChecksumCorrectness. I actually prefer not to put the Is altogether, the name usually remains clear even if you omit it.
Usually I use V=99 when compile my system in order to see the output in verbose mode, my question is related at the 'V' variable, which other type of loggin level can I use with that ?
I analyze a Makefile and I would like see what it is doing, but with V=99 it is really difficult.
Thanks a lot,
Pietro.