design choice: space or comma ?

Started by
15 comments, last by Washu 14 years, 10 months ago
I'm reading in ascii text files for some definitions, like entity startup values, etc.. it is set up by lots of key/value pairs. like: "name" "armor" now I wonder how I would seperate vector(xyz, color, rect,..) values. would you rather seperate them via spaces: "rect" "50 50 200 100" "color" "0.5 0.2 0.9 1" or via commas: "rect" "50,50,200,100" "color" "0.5,0.2,0.9,1" I tend to use comma, but when its in combination with dots it feels weird( probably because in my language, floating point values are written with comma instead of dots) sometimes I find myself stuck with simple questions as this one :-\
Advertisement
space certainly tends to be a lot more locale friendly than "," or ".". You could also use xml attributes and be even cooler! <rect x='50' y='50' width='200' height='100'/> ftw (and now i know what those 4 random numbers mean too! readability ftw!)!

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

You could just accept either, so the user can type whatever they feel like.

But wait.. if floating point values are written with commas, then how can you use commas as a separator? How would the parser know whether "1,1" is two ones or 1.1 ?
I prefer '|'.

That is just because then I can use the string.Split without really having to worry about hitting a character that might have been used somewhere.

theTroll
Quote:Original post by pinacolada
But wait.. if floating point values are written with commas, then how can you use commas as a separator? How would the parser know whether "1,1" is two ones or 1.1 ?
He's not writing the things in the file in his normal, native notation. He's using the period to denote where the fraction begins, not the comma. With such convention, "1,1" would never be 1.1.

As far as suggesting conventions for your parser... I'm going to second Washu's suggestion on XML. XML is really nice for readability reasons. There are lots of XML parsers you can use in pretty much any language, so writing your parser would be pretty easy too.
[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]
pinacolada, I was talking about my language, not the parser ;>
the float values are all done using dots.
using both separators is not good, I'd rather have a fixed standard.

Washu, xml is not an option, since I store all key/pair values in strings so they can contain any type.
could probably convert them to a string again while loading, but that's not the coding style I wanna follow.
Quote:Original post by TTK-Bandit

Washu, xml is not an option, since I store all key/pair values in strings so they can contain any type.


Um... XML only uses strings.
Quote:Original post by TTK-Bandit
pinacolada, I was talking about my language, not the parser ;>
the float values are all done using dots.
using both separators is not good, I'd rather have a fixed standard.

Washu, xml is not an option, since I store all key/pair values in strings so they can contain any type.
could probably convert them to a string again while loading, but that's not the coding style I wanna follow.


How does that preclude the use of XML? There's nothing in XML that says that x='10' is x holding an int.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

imagine a key/value pair set for an entity:
"name" "armor"
"mins" "-15 -15 -15"
"maxs" "15 15 15"
mins would be a key/value pair.
with xml, this would need to be a key/<variable number of values> "pair" for each attribute.
or it would look something like this:
<entity classname="item" name="armor" minsX="-15" minsY="-15" minsZ="-15" maxsX="15" maxsY="15" maxsZ="15"/>
and this is a very small entity definition. as soon as you add more attributes, it'll get more & more messy.
Quote:Original post by TTK-Bandit
imagine a key/value pair set for an entity:
"name" "armor"
"mins" "-15 -15 -15"
"maxs" "15 15 15"
mins would be a key/value pair.
with xml, this would need to be a key/<variable number of values> "pair" for each attribute.
or it would look something like this:
<entity classname="item" name="armor" minsX="-15" minsY="-15" minsZ="-15" maxsX="15" maxsY="15" maxsZ="15"/>
and this is a very small entity definition. as soon as you add more attributes, it'll get more & more messy.


So what you're saying is that I would actually be able to read the notation and understand it without having to guess what "maxs" "15 15 15" meant. Which btw could be redone as something better in XML, such as (with me making a guess as to what "mins" and "maxs" are...):
<entity classname='item' name='Armor'>    <bounds>        <min x='-15' y='-15' z='-15'/>        <max x='15' y='15' z='15'/>    </bounds></entity>


Because the only reason to use text at all is for human readability. Computers tend to prefer binary input a lot more than they do textual.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

This topic is closed to new replies.

Advertisement