Reputation
2,009
Top tag
Next privilege 2,500 Rep.
Create tag synonyms
Badges
5 10
Newest
 Yearling
Impact
~65k people reached

  • 0 posts edited
  • 0 helpful flags
  • 11 votes cast
Apr
17
answered How to warn other programmers of class implementation
Mar
16
answered Data Flow Diagrams _ context diagrams
Mar
15
comment Why didn't == operator string value comparison make it to Java?
@AndresF. Ok, fair enough.
Mar
14
comment Why didn't == operator string value comparison make it to Java?
@AndresF. And my reply wasn't a dig at your comment, just saying that different languages approach these issues in different ways. :-) I actually like the way VB handles this ... pause for the hisses and boos from the VB haters ... "=" always compares the value (for system-defined types), whether primitive or object. "Is" compares the handles of two objects. That seems more intuitive to me.
Mar
14
comment Why didn't == operator string value comparison make it to Java?
@AndresF. (shrug) In Java, "<" means "less than", while in XML it "opens a tag". In VB "=" can mean "is equal to", while in Java it's only used for assignment. Etc. It's hardly surprising that different languages use different symbols to mean the same thing, or the same symbol to mean different things.
Mar
14
answered Why didn't == operator string value comparison make it to Java?
Mar
14
answered In Java, why were protected members made accessible to classes of the same package?
Mar
14
comment Why have private fields, isn't protected enough?
""sooner or later, you are going to make a subclass of every class" is almost certainly not the case." And more to the point, you will almost certainly not, and you SHOULD certainly not, override every function in a class, and change the usage of every data element in a class. Some things should logically be written in stone for the class to have any meaning.
Mar
14
answered Why have private fields, isn't protected enough?
Jan
22
answered Is it a good practice to avoid constants by using getters?
Jan
20
comment How can I store incomplete records but enforce data correctness?
Sure, that's why I said we can move on. The requirement as written is a contradiction, but we can reasonably infer what the person really meant. Requirements that make no sense as written and that have to be "interpreted" happen quite a lot in this business, actually. That's why I'm not afraid of being replaced by an AI any time soon.
Jan
20
comment Specify optional parameter names even though not required?
@DavidArno When I've written in languages that did not have named parameters, yes, sometimes I have created enums with values of true and false to make the code more readable. But when the language provides named parameters, the code is more clear if you DON'T do this. If I write doFoo(includeManagement) and doFoo(dontIncludeManagement), I make clear what the parameter means but I obscure the fact that it's really a Boolean. But doFoo(includeManagement:=true) has all the advantages of the enum while also making the parameter type clear. And eliminating the enum eliminates clutter.
Jan
20
comment Specify optional parameter names even though not required?
... with the first five lines and the second five lines pushed into subfunctions, and with a bunch of data having to be passed between them, would be painful. Duplicating the code and having two versions, one with the conditional line and one without, would be worse.
Jan
20
comment Specify optional parameter names even though not required?
@DavidArno I don't accept that "many lines of code is a sign of bad design". A function that does many different things is bad design. But a function that copies record A to record B might have many assignment statements to do all the moves, but could be fundamentally very simple. Breaking it in half because of some arbitrary rule that a function shouldn't be more than 50 lines or whatever would be terrible design. And "many lines of code" in this context could be 10. If there were ten lines of tightly-coupled code, and line 6 said IF fooFlag THEN bar+=foo, then breaking into two functions ...
Jan
20
comment How can I store incomplete records but enforce data correctness?
@RubberDuck You don't see the contradiction in saying "these fields are required, but they can be omitted"? They have to be supplied, but they don't have to be supplied? Yes, the REAL requirement is something more like, "these fields are required for the record to be marked as 'complete'" or something to that effect.
Jan
20
answered How can I store incomplete records but enforce data correctness?
Jan
20
answered Specify optional parameter names even though not required?
Jan
20
comment Specify optional parameter names even though not required?
In any case, it's pretty unlikely that we would write ReturnEmployeeName(57) in a real program. It's far more likely that we would write ReturnEmployeeName(employeeId). Why would we hardcode an employee ID? Unless it's the programmer's ID and there's some sort of fraud going on, like, add a little to this employee's paycheck. :-)
Jan
20
comment Specify optional parameter names even though not required?
Whoa!! It's certainly POSSIBLE that a Boolean parameter is used to decide which of two totally separate code blocks to execute. And I heartily agree that that would be a bad thing: yes, you should just have made two functions. But I can imagine a hundred other scenarios. Maybe there are many lines of code in the function and the Boolean controls one tiny distinction. Maybe the Boolean is just passed as part of a WHERE clause that controls which records are retrieved, e.g. WHERE includeManagement = 1 OR level!='M'. Etc. "Boolean parameters are evil" is way too simplistic.
Jan
13
comment Leaving intentional bugs in code for testers to find
Yes, athlete's train. But the analogy to that would be to send your testers to a class. We don't tell athletes at the end of a game that half their touchdowns didn't count because they were part of a training exercise. If we did that regularly -- some parts of the game count and some didn't and we don't tell the players which until the end -- I suspect the players would waste a lot of effort figuring out what parts were real rather than just doing their best. And when you tell a player that his incredible long pass that he was so proud of didn't count, that would have to kill team morale.