I've seen a variety of ways used to set boolean values in INI files:
variable = true
variable = 1
variable = on
variable = yes
Which is the most canonical, common, and/or preferred way?
There's no spec for INI files, but for whatever it's worth, I'll list the behaviour of a few implementations from languages I know.
Python's built-in configparser module offers a getboolean that behaves as follows:
the accepted values ... are '1', 'yes', 'true', and 'on', which cause this method to return True, and '0', 'no', 'false', and 'off', which cause it to return False.
In PHP's parse_init_file, on the other hand:
String values "true", "on" and "yes" are converted to TRUE. "false", "off", "no" and "none" are considered FALSE.
Meanwhile, .NET has no built-in support for INI parsing, but its most popular INI-parsing library, ini-parser, offers no support whatsoever for automatic parsing of values and returns them all as strings. Its Getting Started examples show parsing booleans with .NET's Boolean.Parse, which will accept the strings "true" and "false" (with any capitalisation) and throw an exception if given anything else.
In summary: there is absolutely no consistency on this question between different implementations of INI parsers.
I would recommend:
If you are only going to parse your INI using a single parser, check how that parser behaves and craft your INI to suit its particular implementation.
If you need to support a wide range of parsers (for example, for language interoperability), then either abandon INI as a format entirely, or else entirely avoid using any of the magic boolean values that some parsers understand and instead stick to 1 and 0.
It depends on the parser of the ini file.
The values are always strings.
true/false : In C# I can convert true and false strings directly to bool. Equals readability and easy conversion. less code.
0/1 : I have to convert string 0 and 1 to int before converting to bool. Smaller ini file size. Less readable. more code.
yes/no and on/off I would have to use a if/switch statement. readable. more code.
My preferred way is true/false. Object serialize to true/false, you can use true/false with the sql bit type even though it stores as 0/1. So the only down side would be size which can be minor in most contexts.
Related
I was looking at:
hash_1 = Hash[*[Array("a".."j"), Array(1..10)].transpose.flatten]
So I thought, the return with or without the splat, "*", looks the same - so why
hash_1 = Hash[[Array("a".."j"), Array(1..10)].transpose.flatten] returns {} ?
Hence when I tested
Array(1..10).equal? [*Array(1..10)] => false
Thus
Hash[Array(1..10)] => {}
Hash[*Array(1..10)] => {1=>2, 3=>4, 5=>6, 7=>8, 9=>10}
Please help.
Documentation for Ruby Hash's [] method says you can provide 1) pairs of values which will be used as keys and values, 2) an array of key-value pairs in the form of subarrays, or 3) an object which is convertible to a hash. Hash[*Array(1..10)] with the splat matches the first case, and a quick experiment in irb will show:
irb(main):001:0> Hash.new([1,2])
=> {}
which produces a Hash with a default value of [1,2] but containing no elements. That's what gets passed as the hashable object when you use Hash[Array(1..10)], i.e., without the splat.
As of Ruby 2.4 you get the following warning:
irb(main):002:0> Hash[[1,2]]
(irb):2: warning: wrong element type Integer at 0 (expected array)
(irb):2: warning: ignoring wrong elements is deprecated, remove them explicitly
(irb):2: warning: this causes ArgumentError in the next release
(irb):2: warning: wrong element type Integer at 1 (expected array)
(irb):2: warning: ignoring wrong elements is deprecated, remove them explicitly
(irb):2: warning: this causes ArgumentError in the next release
Hash[]
Hash[] expects an even number of arguments (or one single hash-like argument) :
Hash['a','b']
# {"a"=>"b"}
but
Hash[['a','b']]
# {}
In the second example, there's only one argument : an array with two strings, which doesn't answer to_hash. Depending on the Ruby version, it will display a warning or raise an ArgumentError.
Hash[] with splat
For your example :
Hash[*Array(1..10)]
is the same as :
Hash[1,2,3,4,5,6,7,8,9,10]
# {1=>2, 3=>4, 5=>6, 7=>8, 9=>10}
It's an even number of arguments, so a Hash can be created out of every pair.
Note that with an odd number of arguments :
Hash[1,2,3,4,5,6,7,8,9]
# ArgumentError: odd number of arguments for Hash
There is another problem with your code, or rather with your exploratory test, that wasn't mentioned in the other answers so far:
BasicObject#equal? is true IF AND ONLY IF the argument is the same object as the receiver. Not "an object with the same value", not "an object with the same representation", only if it is the exact same object. In other words, for equal? to be true, there is only one single object involved which is both the receiver and the argument. In your case, there are two objects (even though they have the same value and the same representation), so equal? can never ever return true.
You should not use equal?. It is one of the basic tenets of object-oriented programming that objects can simulate other objects (in fact, OO was invented in a language for simulations), but equal? allows you to distinguish between the real object and its simulation, and thus it breaks OO. I repeat: testing for reference equality makes your code non-OO. Frankly, it shouldn't even be possible in a "true" OO language, and it makes me sad that Ruby has it (although Java is worse, in Java it is even the default equality behavior).
You should (almost) always use ==, which is semantic value equality. In some rare cases, you can use eql? (strict value equality). In the Ruby core libraries and standard libraries itself, eql? is only used together with hash for hash- and set-like behavior. (In fact, the only three places I can think of, where eql? is used in Ruby, is Hash, Set (and SortedSet), and the set-like array operations (Array#uniq, Array#uniq!, Array#&, Array#|, and Array#-).) Never use equal?.
Note: === is a different beast altogether and has nothing to do with equality. (It is kind of an unfortunate name to use three equals signs for something that is not equality.)
I am trying to globalize a simple WPF app. In several questions and/or answers on SO I see one of the following two settings on the binding:
StringFormat=C
StringFormat='{}{0:C}'
What is the difference between these? Are there certain conditions where you would use one over the other?
My understanding is that there is no difference, one is just shorthand and the other explicit. The only condition I can think of where being explicit is beneficial is when you want more control over the format. For example:
StringFormat=Total: {0:C}
Other than that, I'd say keep it simple; XAML is already verbose and shorthand syntax is welcome.
Maybe read up string formatting?
http://msdn.microsoft.com/en-us/library/dd465121.aspx
You can use {0:C} in a format string where you are filling in a value:
decimal value = 123.456;
Console.WriteLine("Your account balance is {0:C2}.", value);
while, you use the C as a plain format:
Console.WriteLine(("Your account balance is " + decimal.Parse("24.3200").ToString("C"));
they are functionally equivalent as far as the output. It's just a different way to format the data based on the context of how your using it.
http://msdn.microsoft.com/en-us/library/dwhawy9k.aspx#CFormatString
I am creating a new TCL_ObjType and so I need to define the 4 functions, setFromAnyProc, updateStringProc, dupIntRepProc and freeIntRepProc. When it comes to test my code, I see something interesting/mystery.
In my testing code, when I do the following:
Tcl_GetString(p_New_Tcl_obj);
updateStringProc() for the new TCL object is called, I can see it in gdb, this is expected.
The weird thing is when I do the following testing code:
Tcl_SetStringObj(p_New_Tcl_obj, p_str, strlen(p_str));
I expect setFromAnyProc() is called, but it is not!
I am confused. Why it is not called?
The setFromAnyProc is not nearly as useful as you might think. It's role is to convert a value[*] from something with a populated bytes field into something with a populated bytes field and a valid internalRep and typePtr. It's called when something wants a generic conversion to a particular format, and is in particular the core of the Tcl_ConvertToType function. You probably won't have used that; Tcl itself certainly doesn't!
This is because it turns out that the point when you want to do the conversion is in a type-specific accessor or manipulator function (examples from Tcl's API include Tcl_GetIntFromObj and Tcl_ListObjAppendElement, which are respectively an accessor for the int type[**] and a manipulator for the list type). At that point, you're in code that has to know the full details of the internals of that specific type, so using a generic conversion is not really all that useful: you can do the conversion directly if necessary (or factor that out to a conversion function).
Tcl_SetStringObj works by throwing away the internal representation of your object (with the freeIntRepProc callback), disposing of the old bytes string representation (through Tcl_InvalidateStringRep, or rather its internal analog) and then installing the new bytes you've supplied.
I find that I can leave the setFromAnyProc field of a Tcl_ObjType set to NULL with no problems.
[*] The Tcl_Obj type is mis-named for historic reasons. It's a value. Tcl_Value was taken for something else that's now obsolete and virtually unused.
[**] Integers are actually represented by a cluster of internal types, depending on the number of bits required. You don't need to know the details if you're just using them, as the accessor functions completely hide the complexity.
I have some programs which make heavy use of libraries with enumerations of error codes.
The kind where 0(first value of enum) is success and 1 is failure. In some cases I have my own helper functions that return bool indicating error, in other cases I bubble up the error enumeration. Unfortunately sometimes I mistake one for the other and things fail.
What would you recommend? Am I missing some warnings on gcc which would warn in these cases?
P.S. it feels weird to return an error code which is totally unrelated to my code, although I guess I could return -1 or some other invalid value.
Is it a bad idea? No, you should do what makes sense rather than following some abstract rule (the likes of which almost never cater for all situations you're going to encounter anyway).
One way I avoid troubles is to ensure that all boolean-returning function read like proper English, examples being isEmpty(), userFlaggedExit() or hasContent(). This is distinct from my normal verb-noun constructs like updateTables(), deleteAccount() or crashProgram().
For a function which returns a boolean indicating success or failure of a function which would normally follow that verb-noun construct, I tend to use something like deleteAccountWorked() or successfulTableUpdate().
In all those boolean-returning cases, I can construct an easily readable if statement:
if (isEmpty (list)) ...
if (deleteAccountWorked (user)) ...
And so on.
For non-boolean-returning functions, I still follow the convention that 0 is okay and all other values are errors of some sort. The use of intelligent function names usually means it's obvious as to which is which.
But keep in mind, that's my solution. It may or may not work for other people.
In the parts of the application that you control, and the parts that make up your external API I would say, choose one type of error handling and stick to it. Which type is less important, but be consistent. Otherwise people working on your code will not know what to expect and even you yourself will scratch you head when you get back to the code in a year or so ;)
If standardizing on a zero == error scheme, you can mix and match both enum and bool if you construct your tests like this:
err = some_func();
if !err...
Since the first enum evaluates to zero and also the success case it matches perfectly with bool error returns.
However, in general it is better to return an int (or enum) since this allows for the expansion of the error codes returned without modification of calling code.
I wouldn't say, that it's a bad practice.
There's no need to create tons of enum-s, if you just need to return true/false, and you don't have other options (and true and false are explanatory enough ).
Also, if your functions are named OK, you will have less "mistakes"
For example - IsBlaBla - expects to return true. If you have [Do|On]Reload, a reload could fail for many reasons, so enum would be expected. The same for IsConnected and Connect, etc.
IMHO function naming helps here.
E.g. for functions that return a boolean value, is_foo_bar(...), or for functions that return success or an error code, do_foo_bar(...).
An Example
Suppose we have a text to write and could be converted to "uppercase or lowercase", and can be printed "at left, center or right".
Specific case implementation (too many functions)
writeInUpperCaseAndCentered(char *str){//..}
writeInLowerCaseAndCentered(char *str){//..}
writeInUpperCaseAndLeft(char *str){//..}
and so on...
vs
Many Argument function (bad readability and even hard to code without a nice autocompletion IDE)
write( char *str , int toUpper, int centered ){//..}
vs
Context dependent (hard to reuse, hard to code, use of ugly globals, and sometimes even impossible to "detect" a context)
writeComplex (char *str)
{
// analize str and perhaps some global variables and
// (under who knows what rules) put it center/left/right and upper/lowercase
}
And perhaps there are others options..(and are welcome)
The question is:
Is there is any good practice or experience/academic advice for this (recurrent) trilemma ?
EDIT:
What I usually do is to combine "specific case" implementation, with an internal (I mean not in header) general common many-argument function, implementing only used cases, and hiding the ugly code, but I don't know if there is a better way that I don't know. This kind of things make me realize of why OOP was invented.
I'd avoid your first option because as you say the number of function you end up having to implement (though possibly only as macros) can grow out of control. The count doubles when you decide to add italic support, and doubles again for underline.
I'd probably avoid the second option as well. Againg consider what happens when you find it necessary to add support for italics or underlines. Now you need to add another parameter to the function, find all of the cases where you called the function and updated those calls. In short, anoying, though once again you could probably simplify the process with appropriate use of macros.
That leaves the third option. You can actually get some of the benefits of the other alternatives with this using bitflags. For example
#define WRITE_FORMAT_LEFT 1
#define WRITE_FORMAT_RIGHT 2
#define WRITE_FORMAT_CENTER 4
#define WRITE_FORMAT_BOLD 8
#define WRITE_FORMAT_ITALIC 16
....
write(char *string, unsigned int format)
{
if (format & WRITE_FORMAT_LEFT)
{
// write left
}
...
}
EDIT: To answer Greg S.
I think that the biggest improvement is that it means that if I decide, at this point, to add support for underlined text I it takes two steps
Add #define WRITE_FORMAT_UNDERLINE 32 to the header
Add the support for underlines in write().
At this point it can call write(..., ... | WRITE_FORMAT_UNLDERINE) where ever I like. More to the point I don't need to modify pre-existing calls to write, which I would have to do if I added a parameter to its signature.
Another potential benefit is that it allows you do something like the following:
#define WRITE_ALERT_FORMAT (WRITE_FORMAT_CENTER | \
WRITE_FORMAT_BOLD | \
WRITE_FORMAT_ITALIC)
I prefer the argument way.
Because there's going to be some code that all the different scenarios need to use. Making a function out of each scenario will produce code duplication, which is bad.
Instead of using an argument for each different case (toUpper, centered etc..), use a struct. If you need to add more cases then you only need to alter the struct:
typedef struct {
int toUpper;
int centered;
// etc...
} cases;
write( char *str , cases c ){//..}
I'd go for a combination of methods 1 and 2.
Code a method (A) that has all the arguments you need/can think of right now and a "bare" version (B) with no extra arguments. This version can call the first method with the default values. If your language supports it add default arguments. I'd also recommend that you use meaningful names for your arguments and, where possible, enumerations rather than magic numbers or a series of true/false flags. This will make it far easier to read your code and what values are actually being passed without having to look up the method definition.
This gives you a limited set of methods to maintain and 90% of your usages will be the basic method.
If you need to extend the functionality later add a new method with the new arguments and modify (A) to call this. You might want to modify (B) to call this as well, but it's not necessary.
I've run into exactly this situation a number of times -- my preference is none of the above, but instead to use a single formatter object. I can supply it with the number of arguments necessary to specify a particular format.
One major advantage of this is that I can create objects that specify logical formats instead of physical formats. This allows, for example, something like:
Format title = {upper_case, centered, bold};
Format body = {lower_case, left, normal};
write(title, "This is the title");
write(body, "This is some plain text");
Decoupling the logical format from the physical format gives you roughly the same kind of capabilities as a style sheet. If you want to change all your titles from italic to bold-face, change your body style from left justified to fully justified, etc., it becomes relatively easy to do that. With your current code, you're likely to end up searching through all your code and examining "by hand" to figure out whether a particular lower-case, left-justified item is body-text that you want to re-format, or a foot-note that you want to leave alone...
As you already mentioned, one striking point is readability: writeInUpperCaseAndCentered("Foobar!") is much easier to understand than write("Foobar!", true, true), although you could eliminate that problem by using enumerations. On the other hand, having arguments avoids awkward constructions like:
if(foo)
writeInUpperCaseAndCentered("Foobar!");
else if(bar)
writeInLowerCaseAndCentered("Foobar!");
else
...
In my humble opinion, this is a very strong argument (no pun intended) for the argument way.
I suggest more cohesive functions as opposed to superfunctions that can do all kinds of things unless a superfunction is really called for (printf would have been quite awkward if it only printed one type at a time). Signature redundancy should generally not be considered redundant code. Technically speaking it is more code, but you should focus more on eliminating logical redundancies in your code. The result is code that's much easier to maintain with very concise, well-defined behavior. Think of this as the ideal when it seems redundant to write/use multiple functions.