Reputation
1,889
Top tag
Next privilege 2,000 Rep.
Edit questions and answers
Badges
5 10
Newest
 Yearling
Impact
~59k people reached

  • 0 posts edited
  • 0 helpful flags
  • 7 votes cast
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.
Aug
26
awarded  Yearling
Jun
8
comment Clean Code comments vs class documentation
... describes the purpose of the following lines. I have complied with the rule to not write comments. Is this better? I would say absolutely not, it is far worse, because the reader may be confused into thinking that this variable actually does something, rather than just being a name added to the code to act as a fake comment. That is very similar to the suggestion of writing a dummy subroutine whose only purpose is to provide a name that serves as a comment.
Jun
8
comment Clean Code comments vs class documentation
@EricKing So if you can express "meaning" and "descriptiveness" in code rather than comments, that's a good thing. I'd agree with that in principle. But the idea of moving code to a function just so you can give the function a name rather than writing a comment is applying this rule in a pedantic, irrational manner. The only gain in using the function name is that you comply with this rule. How about if instead of writing the comment, I added a line of code that said, "bool adjust_for_leap_year = true;". Then I never use this variable again. Now I don't need the comment, because the "code" ...
Jun
8
comment Clean Code comments vs class documentation
@phresnel If a function is only called from one place, and you only created that function so that the name could serve as "self-documentation", then the fact that the compiler can enforce parameter types is irrelevant. The only reason the function exists is to have a name, and while the compiler can enforce that the name in caller and callee match, it can't enforce that the name accurately describes what the function does, which is the only reason why this function exists. So the one thing that matters, the compiler CAN'T enforce.
Jun
5
comment Clean Code comments vs class documentation
@Ericking Hmm, saying that instead of writing an "adjust for leap years" comment you should move the two lines of code to a function and name it "AdjustForLeapYears" sounds to me like you are just using a function name as a comment. How is this better than writing a comment, other than that it conforms to an arbitrary rule that you shouldn't use comments? That's like saying that "goto"'s are bad ... so I wrote "#define jump goto" so now I can write "jump" instead of "goto" and the problem is solved! :-)
Jun
5
answered Clean Code comments vs class documentation
Apr
17
comment Why do I need to map arguments to instance variables?
I don't see how it throws away type safety. Most of the rest of what you said I agree with and conceded above. It works in situations where many constraints apply, i.e. none of the above issues come up. But that's actually a pretty large number of cases that I come across. If an object calls for a long parameter list in a constructor, odds are that most of that data is of the in-and-out type, i.e. the object is a place to hold bunches of data about a customer or a product or whatever, and most of that data doesn't affect the logic, it just gets read, stored, and updated.
Apr
17
answered Why do I need to map arguments to instance variables?
Apr
6
comment Why are people making tables with divs?
@DavidW Exacty. And I'd add: the design of HTML, CSS, and JavaScript came about through a series of fits and starts and divergent goals and changes of mind. Just look at the number of deprecated tag attributes in HTML 5! If the thing had been cleanly designed from the beginning, maybe some of these issues would just never have come up. As is, we have to work with what we have. (PS I don't say this to demean the people who invented these tools. There had to be some real geniuses in there. That's just how life is. Nobody knew where it was going when is started.)