Tag Info

New answers tagged

2

What practices can I use to maintain the code clean and avoid series of if/else cluttering the code Though your original plan sounds a little bit crazy, if you replace the requirement of "every ticket" by "a lot of different features", then the above questions makes IMHO a lot more sense. To my experience, the key to keep code maintainable when having a ...


5

I would like to be able to abstract each ticket developed by the team in a way that it can be enabled or disabled at runtime by using a distributed shared configuration system. Ideally yes, everything. I won't go down this path, but I think being able to toggle immediately any change, at runtime, is a very powerful feature. I am just wondering if ...


3

So you effectively need (or just want?) to have two source codes for the pre-ticket and post-ticket situation - e.g. ticket modified behavior of one method, so you ideally want to be able to switch from the former implementation (pre-ticket) of the method to the new (post-ticket) implementation. This can be done using polymorphism - you have some e.g. ...


1

In examining problems and possible solutions, it helps me to use a method popularized by Jeff Atwood: If God were to create a way to store sensitive configuration information, how would he do it? Well, he would know who needs configuration information and only give it to those people, and the information would never be able to be accessed by anyone else. ...


0

I think your options are somewhat defined by the OS you are deploying to I would suggest, yes put the values in source control. BUT only the 'dev' versions. You want your source code to compile AND work! not include extra secret steps Your build and deploy process should then swap these values out per environment during deployment. (octopus has this kind ...


1

Possibly there is no one good answer to this. It seems that you need to store this data somewhere safe, as it will be needed for disaster recovery purposes one day. This applies equally to properties files and scripts that set environment variables. With the source code (in SVN/GIT etc) is a really bad idea, as this data will contain production database ...


3

This answer is specific to C++ (as indicated by the tag on this question). Most other compiled languages (outside C and C++) do not have such consideration, because in those languages there is no benefit in moving configurations to compile-time. Outside of C and C++, conditional compilation is greatly discouraged or simply unsupported. Also, C and C++ ...


1

The title hints that the topic is somewhat opinion-based. However, let's ignore this issue and address the question. I think the pros and cons are fairly obvious, since both methods are just trade offs. For example, let's say you've implemented a runtime configuration-system. Cons: What do you do if some values are missing in the config / the config ...


1

Your decision whether to have code-based configuration or file-based configuration will depend entirely on whether or not you need the flexibility of configuring at runtime vs. compile time. Performance is almost certainly a non-issue, since you can cache the values once they are read from the configuration file.


0

The right approach for this is to have the configuration information in a worksheet - then it can be changed even by people who don't want to touch VBA. The architecture is to have a macro-enabled worksheet with a sheet called, say, Configuration, with each piece of configuration in a cell which is a named range that the macro can refer to. You should have ...



Top 50 recent answers are included