There's a fine line between "elegant code" and "just what the fuck have you done here?"
Like attaching a textbox to a button.
I was never really clear on what you'd meant by that one... it *could* be crazy, or it could be just badly implemented, or both! (my money on the last one)
I mean, MS went "how about we attach TWO Button objects to a MaskedTextBox, make those buttons really small and right-aligned and then we'll call it a NumericUpDown." Which is a control I have a love/hate relationship with. :P
0
Options
Mr_Rose83 Blue Ridge Protects the HolyRegistered Userregular
There's a fine line between "elegant code" and "just what the fuck have you done here?"
Like attaching a textbox to a button.
I was never really clear on what you'd meant by that one... it *could* be crazy, or it could be just badly implemented, or both! (my money on the last one)
I mean, MS went "how about we attach TWO Button objects to a MaskedTextBox, make those buttons really small and right-aligned and then we'll call it a NumericUpDown." Which is a control I have a love/hate relationship with. :P
Yeah, I'm still having trouble visualising the output with that button/textbox combo. Was there just a textbox hanging out near the button in question? Could you click the textbox to activate the button? Or was the textbox on the button? Was it, in fact, a textbutton?
These are static sizes direct from Microsoft. Those are the max number of rows and columns for xls and xlsx files. I doubt that one day we'll need to change them.
One would assume you'd have a hard row/column limit internal to your app. Because if you externalize it, you introduce the possibility of overflow issues.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
These are static sizes direct from Microsoft. Those are the max number of rows and columns for xls and xlsx files. I doubt that one day we'll need to change them.
Sarcastic answer: Because Microsoft never changes their minds about anything.
Alternate answer: Magic numbers are yucky and have cooties.
Serious answer: If you have to add any additional settings, the file is already there for you to use.
But, at that point, I'll have to edit the code anyway to actually LOOK for that data. I understand if the data is volatile because then you can create specific things for specific scenarios.
But this is the max row/column size. If they change it then I will change my code:
But, at that point, I'll have to edit the code anyway to actually LOOK for that data. I understand if the data is volatile because then you can create specific things for specific scenarios.
But this is the max row/column size. If they change it then I will change my code:
You should be able to manually edit the properties file of an existing jar without rebuilding if necessary. That won't be possible if you hard code it(right?).
@GnomeTank I'm trying to get this WPF app running on a system, but, it keeps bitching about .NET 4.5 (which isn't supported on windows 2003).
I've set the targeted framework to everything but .0, it refuses to work (bitching about .NET 4.5) , do you know of any reason why it would be doing that?
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
But, at that point, I'll have to edit the code anyway to actually LOOK for that data. I understand if the data is volatile because then you can create specific things for specific scenarios.
But this is the max row/column size. If they change it then I will change my code:
But, at that point, I'll have to edit the code anyway to actually LOOK for that data. I understand if the data is volatile because then you can create specific things for specific scenarios.
But this is the max row/column size. If they change it then I will change my code:
If I run into a maximum, the application will almost certainly tell me what the max is in decimal, and if I need to go and edit it, the hex delivers information about the source of the number to me that would be useful in my modification.
Because some poor schlub 5 years from now is going to look at it and have to bust out a calculator to figure out the max range of those numbers unless they're really good at hex conversions in their head.
0xff might be easy to remember as 255, but 0x100 is going to look strange unless I sit there.
256 is pretty obvious though.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Because some poor schlub 5 years from now is going to look at it and have to bust out a calculator to figure out the max range of those numbers unless they're really good at hex conversions in their head.
0xff might be easy to remember as 255, but 0x100 is going to look strange unless I sit there.
256 is pretty obvious though.
Why do you need to know that maximum before you run into it? If your plan is to edit that number, it's probably because you've hit the max, and so you know what the max is already. If you're preemptively editing it to make sure you never run into it, then you don't need to know what it's at now, you need to know what it needs to be. You go into the file, see it's in hex, and then find the next greatest number 2^n after your space considerations.
I think it would be kind of an edge case to go into a file like that and be like "okay guys, remember not to use more than 256 columns"
I see very very little reason to write any number 2^n in decimal.
[EDIT] I see very little reason to write any number which represents a raw binary in decimal.
You don't think readability is a good enough reason?
If something represents an amount of space, I'm generally used to seeing it represented in hex, precisely because the hex numbers are more readable than decimal numbers when dealing with bits.
Like, in this case, the hex notation is delivering information that you're dealing with bits, and so an arbitrary decimal number might not be appropriate!
But, at that point, I'll have to edit the code anyway to actually LOOK for that data. I understand if the data is volatile because then you can create specific things for specific scenarios.
But this is the max row/column size. If they change it then I will change my code:
You should be able to manually edit the properties file of an existing jar without rebuilding if necessary. That won't be possible if you hard code it(right?).
That is an interesting observation and hadn't thought about it. If I had data that would potentially be changing in the future then I would most certainly put them in props files.
You're telling me the second number is easier to read to you? In your head you're not converting it back and going "Welp 0x100 is 256, carry on then".
No, I'm not converting it at all, because if it's a limit, it's extremely unlikely I need to know exactly what the limit is. 0x100 vs 0x1000 vs 0x10000 tells me approximately how big it is without having to calculate anything, and if I'm in danger of running into the limit, then I can edit the configuration so that is no longer the case.
The point I'm really trying to make is that I feel like, in this case, the number itself is way less important than what it represents.
Also, my argument hinges entirely on this configuration being editable. If it's pretty much a set constant and you can't do anything about it, then sure, decimal is better, because now there is an absolute wall you have to know about, and suddenly the exactness of that is relevant.
Posts
Second only to LAMP stacks.
Like attaching a textbox to a button.
public ExcelWriterBase(String type) { super(type); InputStream is = ExcelWriterBase.class.getClassLoader() .getResourceAsStream("excel.props"); props = new Properties(); try { props.load(is); is.close(); xlsRowPropMax = new Integer(props.getProperty("xls.row.max")) .intValue(); xlsColPropMax = new Integer(props.getProperty("xls.col.max")) .intValue(); xlsxRowPropMax = new Integer(props.getProperty("xlsx.row.max")) .intValue(); xlsxColPropMax = new Integer(props.getProperty("xlsx.col.max")) .intValue(); } catch (IOException e) { xlsRowPropMax = 0; xlsColPropMax = 0; xlsxRowPropMax = 0; xlsxColPropMax = 0; } }Whyyyy are we reading from a properties file for these values that never change, ever?
I was never really clear on what you'd meant by that one... it *could* be crazy, or it could be just badly implemented, or both! (my money on the last one)
I mean, MS went "how about we attach TWO Button objects to a MaskedTextBox, make those buttons really small and right-aligned and then we'll call it a NumericUpDown." Which is a control I have a love/hate relationship with. :P
Yeah, I'm still having trouble visualising the output with that button/textbox combo. Was there just a textbox hanging out near the button in question? Could you click the textbox to activate the button? Or was the textbox on the button? Was it, in fact, a textbutton?
Nintendo Network ID: AzraelRose
DropBox invite link - get 500MB extra free.
Because it's good habit in case they do
Think like that. Except the textbox overlays the text of the button.
Completely unintentional because they couldn't figure out how to unnest it and put them side by side in a flow panel.
That's what we like to call "dynamic system solutions"
Sarcastic answer: Because Microsoft never changes their minds about anything.
Alternate answer: Magic numbers are yucky and have cooties.
Serious answer: If you have to add any additional settings, the file is already there for you to use.
But this is the max row/column size. If they change it then I will change my code:
You should be able to manually edit the properties file of an existing jar without rebuilding if necessary. That won't be possible if you hard code it(right?).
Nintendo ID: Incindium
PSN: IncindiumX
I've set the targeted framework to everything but
If you're going to remove functionality for magic numbers, at least use constants! And put in comments that those are 2^16, 2^8, 2^20, and 2^14.
Even better, just write them in hex.
xlsRowPropMax = 0x10000;
xlsColPropMax = 0x100;
..
Why is that confusing?
If I run into a maximum, the application will almost certainly tell me what the max is in decimal, and if I need to go and edit it, the hex delivers information about the source of the number to me that would be useful in my modification.
0xff might be easy to remember as 255, but 0x100 is going to look strange unless I sit there.
256 is pretty obvious though.
Why do you need to know that maximum before you run into it? If your plan is to edit that number, it's probably because you've hit the max, and so you know what the max is already. If you're preemptively editing it to make sure you never run into it, then you don't need to know what it's at now, you need to know what it needs to be. You go into the file, see it's in hex, and then find the next greatest number 2^n after your space considerations.
I think it would be kind of an edge case to go into a file like that and be like "okay guys, remember not to use more than 256 columns"
I see very very little reason to write any number 2^n in decimal.
[EDIT] I see very little reason to write any number which represents a raw binary in decimal.
If something represents an amount of space, I'm generally used to seeing it represented in hex, precisely because the hex numbers are more readable than decimal numbers when dealing with bits.
Like, in this case, the hex notation is delivering information that you're dealing with bits, and so an arbitrary decimal number might not be appropriate!
int limit = 0x100;
You're telling me the second number is easier to read to you? In your head you're not converting it back and going "Welp 0x100 is 256, carry on then".
That is an interesting observation and hadn't thought about it. If I had data that would potentially be changing in the future then I would most certainly put them in props files.
No, I'm not converting it at all, because if it's a limit, it's extremely unlikely I need to know exactly what the limit is. 0x100 vs 0x1000 vs 0x10000 tells me approximately how big it is without having to calculate anything, and if I'm in danger of running into the limit, then I can edit the configuration so that is no longer the case.
The point I'm really trying to make is that I feel like, in this case, the number itself is way less important than what it represents.
Whelp! 100 pages. New thread!
Last one out turn off the LAMP stacks, please.
Most of the time it will be big enough, and hard to reproduce!