3,412 reputation
1020
bio website None
location North Carolina
age 49
visits member for 3 years, 5 months
seen 9 hours ago
Software Engineer

9h
comment Are error variables an anti-pattern or good design?
You make the usually false assumption that an exception happening within any of the "someOperation"s can be handled and cleaned up in the same way. What happens in real life is that you need to catch and handle exceptions for each operation. Thus, you don't just throw an exception as in your example. Also, using exceptions then ends up creating either a bunch of nested try-catch blocks or a series of try-catch blocks. It frequently makes the code far less readable. I'm not set against exceptions, but I use the appropriate tool for the specific situation. Exceptions are just 1 tool.
9h
comment Are error variables an anti-pattern or good design?
It isn't a question of silent data corruption. It is a question of understanding your app and knowing when and where you need to verify if an operation was successful or not. In many cases, making that determination and handling it can be delayed. It shouldn't be up to somebody else to tell me when I have to handle a failed operation, which an exception requires. It's my app, I know when and where I want to handle any relevant issues. If people write apps that could corrupt data then that's just doing a really poor job. Writing apps that crash (which I see a lot) is also doing a poor job.
1d
comment Are error variables an anti-pattern or good design?
Arrghhhh! How many times have I seen this "The problem of the error variable is that it is easy to forget to check". The problem with exceptions is that it is easy to forget to catch it. Then your application crashes. Your boss doesn't want to pay to fix it but your customers stop using your app because they get frustrated with the crashes. All because of something that would not have affected program execution if error codes were returned and ignored. The only time I've ever seen people ignore error codes is when it didn't matter that much. Code higher up the chain knows something went wrong.
1d
comment Patent a program: possible or not?
Neither would the guys in the patent office, so your odds of getting it improved will be increased dramatically.
1d
comment Patent a program: possible or not?
You can patent just about anything. All you have to do is get it by the numbnuts at the patent office who haven't got a clue what the difference between an "if" and an "else" is. However, usually you patent an algorithm but you get copyright for the source code. At least that is my non-lawyer understanding. Yes, if you can patent it then go ahead. It looks great on a resume.
Jul
1
comment What is a good C++ API Design for HW registers?
It is also customary to give meaningful names to the enums.
Jul
1
comment Estimated work remaining doesn't get lower
...Then your manager can easily determine there's 20 days of active work but 40 days of SCRs and 30 days of schedule. I guess I'll pick the most important SCRs that adds up to 10 days in order to meet schedule.
Jul
1
comment Estimated work remaining doesn't get lower
The solution is simple, but requires someone a bit anal to manage it. There should be a software process for declaring when code is done. e.g. Coded, Unit Tested, Peer Reviewed, Developer Integration Tested = DONE. Any problems/desired changes found after an item is done goes into a software change request database. Each Change request is prioritized and a ballpark time estimate is recorded. If it is decided to work on a particular SCR then the SCR goes on the schedule as a new item. No need to re-open a closed work item...
Jun
27
comment Passing central objects around or having global instances?
While not using singletons because it makes testing easier gives more immediate gratification, Doc nailed the bigger reason. When all of a sudden you need that 2nd instance, which should never happen, but does. Of course that usually only happens on successful projects because who wants to expand capabilities on applications no one is using. "Developer: We'll only ever use XYZ database so singleton is the obvious choice....some time much later...Manager:We have a potential customer but they want to use ABC database. Developer:That is going to be really, really difficult. NO NEW CUSTOMER."
Jun
27
comment Could taking design lightly be a pitfall of agile methodologies causing constant rework or is it a misunderstanding of the methodology?
@Neil:I didn't take it personally, that would be extremely difficult for someone to make me do that from a post. I never claimed everything has to go well. Nothing ever goes as planned. No methodology is perfect, but to claim that waterfall doesn't work ignores thousands and thousands of successful projects proving otherwise. Real-world waterfall handles problems and changes quite adequately. And I think it is debatable as to whether agile handles changes better than waterfall or not. It's far easier/less costly to change documentation than to redesign an implementation.
Jun
27
comment Could taking design lightly be a pitfall of agile methodologies causing constant rework or is it a misunderstanding of the methodology?
@Neil:I don't have to kid myself. I have 25 years (with a few years of "agile-like" scattered in) and Waterfall not only works, it works very well and for the type of projects I tend to work, it works much better than agile. But the type of projects I work on have to work. It isn't acceptable to simply let the application crash like most commercial software does. My opinion may be biased from that standpoint. So my choice is to base my opinion on what I've actually seen happen in real-life (very successful waterfall-like projects) or take your opinion that you probably came to from reading?
Jun
26
comment Could taking design lightly be a pitfall of agile methodologies causing constant rework or is it a misunderstanding of the methodology?
@Neil:Nobody believes that waterfall will let you code it right the first time. But it should get you quicker to the architecture that handles all your needs. Waterfall-like continues to be used by many companies because IT WORKS when the people have sufficient skill using the process. Granted, it is much harder for newbies to develop the skills to make waterfall-like work. It is far easier to get those happy day prototypes "working" using agile. Most of the agile apps/teams that I've had to save didn't plan the unhappy paths, which is the hard part and tend to require large rewrites.
Jun
26
comment When to stop reviewing code?
@Cs:In order to have your company certified for adhering to various standard processes (e.g. ISO/MIL-STD/IEEE/DoD) you have to document the process. Code Review is very much a part of those certifications. That also means its part of the bid process and code review time is quoted as a separate activity. So it can't be some hidden task in many cases. Even if it were, if finding bugs and identifying uncovered what if scenarios weren't the key component then it is really a waste of time compared to other tasks developers could be doing with their time instead, like getting the product working.
Jun
25
comment When to stop reviewing code?
I couldn't disagree more. What you are describing as the purpose of code reviews are the least important reasons. FINDING BUGS is the overwhelming reason for code reviews. The other stuff is just a by product. Code reviews take a lot of time. If the purpose of code reviews is what you describe then there aren't going to be many (if any) customers willing to pay for them. Customers will pay for code reviews because they believe it will find bugs sooner rather than later, like when they are 30,000 feet in the air.
Jun
23
comment Is it an antipattern, modifying an incoming parameter?
TryParse in C# uses the pattern. I prefer TryParse to using an exception handler which is necessary when just using Parse, but that's just my preference.
Jun
18
comment What is the best way to get a method name in runtime?
Ummm...how could this question be language agnostic?
Jun
16
comment Adding a minimum rectangle overlap threshold
Everywhere you use r1.x replace with (r1.x - threshold). Everywhere you use r1.y replace with (r1.y - threshold).
Jun
5
comment Where should instantiated classes be stored?
The only 1 I wouldn't even consider choosing is option 3. You don't define a new class just because an instance contains different data values. Can you say "Class Explosion".
Jun
3
comment Infinite loop with a singleton - does this type of issue have a name?
You avoid this problem by drawing a class diagram and being aware of dependencies. Cyclic dependencies should be eliminated. In your case, A knows about B. B knows about S which implicitly means it knows about A. That's a problem. There is seldom a need for 2-way dependencies. A class shouldn't know who contains it.
Jun
3
comment Infinite loop with a singleton - does this type of issue have a name?
This problem has nothing to do with a singleton. You would have the same problem even if Singleton was not a singleton. Creating a new S causes A's constructor to be called which causes B's constructor to be called which causes a new S to be created which causes A's constructor to be called which causes B's constructor to be called which causes a new S to be created which causes A's constructor......