Reputation
351
Top tag
Next privilege 500 Rep.
Access review queues
Badges
1 6
Newest
 Caucus
Impact
~6k people reached

  • 0 posts edited
  • 0 helpful flags
  • 43 votes cast
Sep
15
comment When is it ok to assert for a pointer being non-null?
@BЈовић I'm not saying exceptions are wrong to use, I'm just saying they are not a big shiny hammer that should be used for everything. IMO exceptions should not be used to hide programming errors. Programming errors should be visible as soon as possible, ideally at compile time, or in a test. Someone putting illegal arguments into a library is IMO a programming error. And no one was talking about console either, even though a lot of what we write don't directly have a UI (embedded), so it's not that uncommon.
Sep
15
comment When is it ok to assert for a pointer being non-null?
@BЈовић If the exception is thrown due to a programming error I would still much rather have it fail during development. If I write an internal only library which have hard requirements on inputs, I would not hesitate to have it assert on that. The user will then get a proper error thrown in his face that he have to fix before going into production. Crashing programs are annoying, but programs that suddenly gets weird behaviour because they are trying to conceal bugs are IMHO even worse.
Sep
15
comment When is it ok to assert for a pointer being non-null?
@BЈовић If it hides errors or not really depends on how you catch the exception. In my opinion a catch_all exception is way to common (I actually have a running argument with a colleague about it now). So for exceptions you assume the user can recover from, throw an exception and let someone try to recover. For other errors the best thing to do (IMHO) is just to die and flag to the developer that it went wrong. Dying at a customer location is of course bad, but the danger of hiding errors is in my opinion far too real.
Sep
14
comment When is it ok to assert for a pointer being non-null?
I disagree with you that it's never ok to assert. I would much rather assert and have a clear error as soon as possible, than "hide" the root cause of the issue. Failing fast is IMHO a completely valid way of avoiding the user seeing the errors, as they will be really prominent during development.
Mar
5
comment What are the problems of bringing C++-like const into a language?
I completely agree with Doval. "Const poisoning" is not a problem, as long as you always mark functions const when they really are const. And if an external library says a function your're calling is not const, then you can no longer guarantee constness of your function and can not mark it as const, simple as that.
Aug
20
comment Is a well written documentation a good enough reason for learning a programming language?
There is a fourth reason I think you have skipped: Because the language looks fun!
Jun
20
comment What's with the aversion to documentation in the industry?
+1 for "If your code is so hard to read that you need comments, wouldn't time be better spent cleaning the code?" In my experience code and documentation seldom tells the same story.
Mar
14
answered Scrum Master in the organization
Mar
5
awarded  Caucus
Jan
25
revised Git: rebasing on top of a refactor that affects the target rebase branch
added 499 characters in body
Jan
24
answered Git: rebasing on top of a refactor that affects the target rebase branch
Jan
17
comment Refactoring: Two big chunks within a function
+1: Only thing I am not sure about is if a and b should be re-inlined anyway. If you make this method call either a or b, it is already doing one thing, it is deciding which route the code should go. Then it's the subroutines that are responsible for doing the actual work. At least my take on it. But yeah... I think he should do the obvious refactoring first, and see where it takes him.
Jan
15
comment How should I distinguish between built-in types in Python?
True. Given that the lookup is as easy as you assume in your code.
Jan
15
comment How should I distinguish between built-in types in Python?
I agree. Ideally I would have had two functions: lookup_person_dict, lookup_person_string and force the user to be specific. The problem I find with this is that you basically use a try/except block for control flow, is a big no-no in my eyes. However, having a function which accepts both string and hashmaps is also a no-no in my eyes, and so this exception flow is the cleanest alternative I can think of at least.
Jan
4
comment Is it necessary to add the default case while using switch cases?
In case 1 and 2, a default case should be an error. If your coding style always use default, then do that, but make it emit an error in 1 and 2. Is possible, it should emit it at compile time, but that might not always be possible, if ever in java. I at least think it's important for the user to get the message that "You are shooting yourself in the foot by passing in this value"
Jan
3
comment Should I use the new C++11 'auto' feature, especially in loops?
@fish: range based for-loops rules, but I would have been pedantic and done: 'for (T& it : x)' instead when using range based for-loops, as I feel using auto there is less informative. Kind of a misuse of auto in my mind.
Dec
15
comment How do you balance between “do it right” and “do it ASAP” in your daily work?
As Uncle bob says: The slow way is the fast way. Take the time it takes to write those unit tests, and write your code well. This might cause it to take some more time for the feature to be implemented, but will save time in the long run as it will be easier for others to modify and fix bugs in.
Dec
14
comment Why does the Scrum guide say no testers?
@Maxood: Testers should, in my opinion, not touch unit tests. They should work on acceptance tests, in cooperation with developers, and have responsibility for the manual/GUI testing. The unit testing is on a level that is only interesting for the developers. The test pyramid (blogs.agilefaqs.com/2011/02/01/inverting-the-testing-pyramid) also has responsebilities, Unit-testing=developers, acceptance testing = shared, GUI testing = testers.
Dec
14
comment Review tests first
I understand your concern, and it is therefor the test should never pass the first time. A TDD cycle goes like this: 1) Write the minimal, sane, test needed for the tests to fail. 2) Write only the production code you need to pass that test. 3) Refactor 4) goto 1. Clearly, you should try your test before even starting writing production code, to verify that your test will catch that bug/missing feature. Then you should implement enough of the feature to make the test pass, refactor, and then write a new minimal test.
Oct
26
comment How do operating systems… run… without having an OS to run in?
And even more incredible if you go from desktop to embedded. 1) Hardware looks for a bootloader in a given sector on disk. 2) Bootloader runs from disk and sets up memory and GPIOs. 3) Bootloader loads itself into the memory. 4) Bootloader finds kernel and loads it into memory. 5) Bootloader dies, and kernel lives. This of course, requires detailed knowledge of the memory addresses on the board, as well as what type of memory is used. Or to say it in other words: U-boot load the kernel by magic!