Timeline for Using nested public classes to organize constants
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 27, 2012 at 15:55 | comment | added | kevin cline | @FrustratedWithFormsDesigner: UI-field IDs? Don't know where to find a value? Sounds like a huge pile of WTF. You have my sympathy. | |
| Oct 26, 2012 at 21:32 | comment | added | KChaloux | A constants class that's constantly changing... there's something zen in there, if you dig hard enough. | |
| Oct 26, 2012 at 20:53 | comment | added | FrustratedWithFormsDesigner | We currently have one Constants file that contains most of the UI-field ID constants, and a couple of other constants files that are subproject-specific. But now, the subproject-specific constants are needing to be used by other related subprojects so that's what prompted the idea to merge them all to one "master" constants file. Which is better than now because sometimes I don't even know which constants file to refernece for a value, and someone else created a duplicate of a constant because they couldn't find it in a different subproject's constants file. | |
| Oct 26, 2012 at 20:47 | history | edited | kevin cline | CC BY-SA 3.0 |
added 227 characters in body
|
| Oct 26, 2012 at 20:41 | history | answered | kevin cline | CC BY-SA 3.0 |