Reputation
1,015
Next privilege 2,000 Rep.
Edit questions and answers
Badges
8 15
Newest
 Yearling
Impact
~386k people reached

Jan
26
awarded  Yearling
Jan
12
comment Designs and practices to guard against erroneous null entries from database
In response to comments about getting additional approvals for changes of this kind: my point about the values being "incorrect" presupposes that the allowable values are already documented somewhere -- that's why the OP says that these values should be considered a bug. If the schema of the database is specified to allow a value, then that value is not a bug. The point is that if you have data that doesn't match your schema, then something is broken: your priority should be to make the data and the schema match. Depending on the team, that may involve changing the data, the schema, or both.
Jan
10
comment Do dynamically typed languages, such as Ruby and JavaScript, do any dynamic type checking?
I'll just add a plug for my favorite essay on this subject: Chris Smith's What to know before debating type systems.
Jan
6
comment Designs and practices to guard against erroneous null entries from database
@JeffO: No committee should be debating whether to store "NA", "None", NULL, or something else in the database. Non-technical stakeholders have a stake in what data comes out of the database and how it is used, but not in the internal representation.
Jan
5
answered Designs and practices to guard against erroneous null entries from database
Sep
6
awarded  Cleanup
Sep
6
revised Why do languages such as C and C++ not have garbage collection, while Java does?
rolled back to a previous revision
Aug
21
comment Automatically reverting commits that fail the build
This is indeed the right answer -- the right solution is to prevent bad changes from ever reaching the master branch, not to let them land and then have to deal with rolling them back.
May
23
comment How do you avoid getters and setters?
@RolandTepp: I don't really want to derail the comments on this question. But my point was that omitting the "get" prefix is also a valid idiom in Java. Since there are multiple possible idioms which are both in wide use (see my previous comment, which you say you do not disagree with), I don't see how adopting one idiom over another -- in contexts where you have the choice -- is "pure hubris" or results in reduced code readability. You are free to disagree, and I don't begrudge you your opinion. Perhaps you should open a separate question about the naming convention?
May
21
comment How do you avoid getters and setters?
@RolandTepp: You're saying that naming a method size() or ordinal() rather than getSize() or getOrdinal() is not idiomatic? Better change all collection types in the standard library and the definition of enums in the language spec then, because those don't use the "get" prefix. There are plenty of other examples I can find. Basically: I reject the premise that the "get" prefix is an idiom of the language, only of some libraries of the language.
May
20
comment How do you avoid getters and setters?
@RobertHarvey: Are we talking exclusively about enterprise Java here, though? Like I said in my comment above, I personally think you should avoid specs like JavaBeans if you don't need them -- but if you do need them, then yeah, ignore my advice. :-)
May
20
comment How do you avoid getters and setters?
@IntelliData: It depends on what you're modeling Customer to mean. If you model Customer to mean "the knowledge I have about a customer at a point in time", then it can freely be immutable; when you have more knowledge you just create a different instance. In fact that can be a much easier way to model data if you have both local (in-memory) and remote (database) structures: the Customer object in memory will by necessity not always be identical to the Customer record in the database, so being able to represent them differently (and being to compare between them) can be very useful.
May
20
comment How do you avoid getters and setters?
@RobertHarvey: They are indeed, and that's a good way to articulate why I don't like the name(new_name) form. I don't believe that naming methods after verbs is a hard rule though, so I have no objection to naming a (non-state-changing, obvious-from-context) method after a noun. I realize that not everyone concurs with this opinion, though.
May
19
comment How do you avoid getters and setters?
@IntelliData: As a method with no arguments, it cannot be a setter. The pattern of using methods named after the properties exists throughout the Java standard library (Collection.size() for example) and is quite common in other languages as well (I see it a lot in C++ code, for example). I've seen people make name() the getter and name(new_name) the setter, although I'd shy away from that in favor of having an explicit setName(), or better yet omitting setters entirely. IMO, value objects should always be immutable unless there's a strong need for them to be otherwise.
May
18
comment How do you avoid getters and setters?
...and, from the opposite perspective from MichaelT: if you're not using the JavaBeans spec (and I personally think you should avoid it unless you're using your object in a context where it's necessary), then there's no need for the "get" wart on getters, especially for properties that don't have any corresponding setter. I think a method called name() on Customer is as clear, or clearer, than a method called getName().
Apr
6
awarded  Nice Answer
Mar
27
comment What causes floating point rounding errors?
@robert: The point I was trying to make was that the OP's premise for this question is not necessarily valid. Floating point math doesn't introduce more error than fixed point -- actually it can introduce less error (especially relative to bits used). There are good reasons to use fixed point or decimal floating point, but "not understanding how binary floating point behaves" isn't a good reason IMO. And BTW, no, .NET's decimal isn't like BCD at all -- it has a mantissa and exponent, just in base 10. BCD is a whole other kettle of fish. :-)
Mar
27
comment What causes floating point rounding errors?
You can do floating point numbers in base 10 -- that's how .NET's decimal type works. Fixed point, on the other hand, is different. As long as your range is limited, fixed point is a fine answer. But the restrictive range makes fixed point unsuitable for many mathematical applications, and implementations of fixed point numbers are often not well optimized in hardware as a result.
Mar
27
comment What causes floating point rounding errors?
@robert: That's not exactly what I was referring to. The "error" most people encounter with floating point isn't anything to do with floating point per se, it's the base. IEEE-754 floats and doubles use an exponent in base 2, which means that fractional numbers round off to negative powers of two (1/2, 1/16, 1/1024, etc.) rather than negative powers of 10 (1/10, 1/1000, etc.) This leads to unintuitive results like 0.1 rounding to 0.1000001 and similar issues.
Mar
18
comment When is it a good idea to force garbage collection?
@JimmyHoffa: you say "everything that Main() references ... will be rooted until your Main() returns at the end of your process." That's not necessarily true. An object can become eligible for collection during execution of a method on that very object.