New answers tagged

0

If you have many configuration properties across multiple application, than my recommendation would be to build a simple CCM. else its better to use config file. Here is the simplest way to load them, Properties result = null; String propertyFilePath = ""//<PATH to config file>; you can manipulate with String path = ...


2

There are a couple options that present themselves in this case. The first, is the properties file. Its location is somewhere and typically in the class path. Typically, you will see it coupled with the getResource family of calls. Properties prop = new Properties(); prop.load(this.getClass().getResourceAsStream("stuff.properties"); Now, if you don't ...


1

I assume these are really constants, not configuration values - i.e. they don't change between invocations or deployments. In that case I'd store it in Java files - no complicated parsing from the config file, you can leverage type safety etc. Your approach with enums is fine for a lot of cases, but the problem here is the number of attributes - enum ...


0

Did you make the changes based on any specific end user requirements? If yes, it is worthy to users to have that change. If no, did you consider "fully configurable behavior" is really desirable for any foreseeable future requirements that you will definitely implement? If yes, it "maybe" worthy for future changes. I said "maybe" because you can only ...


3

There is no hard-and-fast rule. But this question should always be considered carefully when thinking of redesigning a system. In general, it is very bad practice to hard-code any settings into your program. Configuration settings and large external values should always come from files. This separation of data and code (or logic) should, for any reasonably ...


1

It sounds like you're weighing the cost of code that's a little more difficult to understand than the original code against the benefit of being able to "swap, add, or remove columns from spreadsheets or databases without breaking the programs behavior", as well as optimizations that speed things up by (up to) a factor of 10 (and maybe more?). Only you can ...


2

For embedded programming, it is usually preferable to have the constants at the top of the source file. This is to ensure readability and ease to change the value quickly without having to delve into the code and modify them. #include <thisLibrary.h> #include <thisOtherLibrary.h> #define USART_BAUD_RATE 10000 #define SOME_OTHER_VALUE 1234 For ...


2

If the user should be able to change the values, putting them in the code as constants is obviously not an option. A text file with key-value pairs seems appropriate (concidering it is for a small project). In general you should ask yourself if you want to tie your settings to a group of users, the machine, the program file or the individual user. You may ...



Top 50 recent answers are included