Tag Info

New answers tagged

1

I would avoid creating constants (magic values) to convert a value from one unit to other. In case of converting I prefer a speaking method name. In this example this would be e.g. DayToSeconds(num_days) internal the method don't need magic values because, the meaning of "24" and "60" is clear. In this case I'd never use seconds / minutes / hours. I would ...


4

Hardcoded strings are not a problem. Let them be. What you should have though is functions wrapping the queries so each of the identifiers is only used once in the code. If you have more than one place where you need the strings, creating constants for them makes sense, because the compiler will make sure that they are consistent. But if you have one place ...


3

When you take time to study elegance outside the constructs of code, you gain an appreciation for what truly is elegant. According to the great art masters (like Da Vinci), and some of the greatest mathematical minds (like Einstein), a very common attribute of elegance is simplicity. What Elegance Is Not In reading your question, it seems to me that you ...


3

Isn't striving for elegance counter-productive? Past a certain point, yes. But is it really worth it? I am not asking what is elegant; neither am I asking about good code. I assume that "you know it when you see it" Well ... you probably should [ask "what is elegant"]. "You know it when you see it" implies that you don't know it, until you see ...


2

it can also be vaguely characterized by verifying that there is nothing left to take away, in a sense that the mental model you have in your mind is expressed directly and unobscrured in the language of your choice (programming language, object oriented design, relational schema etc.), without distractions. I'm not sure I agree with this. I know of many ...


4

I see no justice in this statement: ... by striving to develop elegant solutions maintainability necessarily suffers. The most elegant solutions are the most tightly coupled to the problem domain, for if they weren't, then there would be something to take away from it, hence they would not be most elegant anymore. An example of an elegant ...


2

However, the open/closed-principle states that this should not be necessary. This isn't a useful interpretation of the open/closed principle. There's always a requirement your design can't accommodate. Think of it this way - a program can be thought of as a domain-specific library whose components are combined in a particular way by the main function to ...


0

The biggest thing I would suggest is that a class should consider void any contracts with callers that use it improperly, but improper usage by one caller should not affect the validity of contracts with other callers. Suppose, for example, that a class implements "Popsicle Immunity" and promises that if IsFrozen returns true, all subsequent observations of ...



Top 50 recent answers are included