Ben Cottrell

United Kingdom

Age: 33

May
1
comment What are the benefits of an input/output component design?
Changing the design of software isn't likely to do very much to change your delivery timescales. If anything, changing a design of an already late project is extremely likely to make it even later - especially where part of your proposal is to introduce some new and unfamiliar tools and practices to the development team. Failings of a late project are nearly always down to the way the project is managed (Chances are the project was already doomed before even a single line of code had been written), and as such, can only be solved through better project management.
Apr
23
reviewed Approve suggested edit on Theoretically bug-free programs
Apr
23
reviewed Approve suggested edit on Can I safely ignore byte order in networking?
Apr
17
comment How to write correct loops?
Under what circumstances do you believe that j >= 0 is a mistake? I would be more wary of the fact that you are accessing array[j] and array[j + 1] without first checking that array.length > (j + 1).
Apr
16
revised Best way of writing comments in code
added 151 characters in body
Apr
16
comment Best way of writing comments in code
I think the problem with that approach is it makes the assumption that the next developer will understand the reason you've done everything; what's obvious to you may not be obvious to the next person. I think it's better to pessimistically assume that your code does have issues, and that future developers will be confused by your code no matter how great your names are, or how clean/SOLID/DRY your code is. It only takes a minute to write a couple of short insightful comments; if that prevents a future developer making an "obvious" mistake, then it's a good time investment IMO.
Apr
16
comment Best way of writing comments in code
External documentation is not appropriate for explaining why individual bits of code do a certain thing, because you would need a way of referencing the bit of code which they talk about; and since code tends to change, that would make the documentation go out of date. So really the best place to put that information is within comments in the code itself.
Apr
16
comment Best way of writing comments in code
Code doesn't explain rationale; which are all the things in a developer's head while they're writing code. Code simply documents its own design and what it does. For example, a line of code might be necessary due to some peculiarity of a 3rd-party library, or maybe the code is part of a series of steps in a workflow which isn't obvious from reading the code, or maybe there are known limitations/constraints which affect the system. There are many, many things which developers "think" while writing code which is impossible to capture in the code itself, so the "Why" has to go into comments.
Apr
16
revised Best way of writing comments in code
added 634 characters in body
Apr
16
answered Best way of writing comments in code
Apr
16
comment Best way of writing comments in code
Strongly disagree with "Comments shouldn't even really explain why". Comments are usually the only way for a developer who is unfamiliar with the code to understand the rationale behind it. Somewhere along the line a developer picking up a bit of existing code needs to understand not only which requirements and user expectations it satisfies, but also the assumptions that the original developer made when they wrote the code. All of this is part of the "WHY"; and the absolute best place for that rationale is in the code comments.
Apr
14
revised Principle of least astonishment (POLA) and interfaces
Update based on comments
Apr
14
comment Principle of least astonishment (POLA) and interfaces
But definitely worth adding more notes about DRY and ordering to the answer.
Apr
14
revised Principle of least astonishment (POLA) and interfaces
Update based on comments
Apr
14
comment Principle of least astonishment (POLA) and interfaces
@DanLyons I feel that's rather close to the situation the asker is trying to avoid; where the user of the API needs to know or care about the order. Ideally, the API itself should enforce the order, otherwise it's potentially asking the user to violate DRY. That's the reason for splitting out ContentBuilder and allowing FileWriter.Write to encapsulate that bit of knowledge. The exception would be necessary in case anything happens to be amiss with the content,(e.g. such as a missing header). A return could also work, but I'm not a fan of turning exceptions into return codes.
Apr
14
awarded Nice Answer
Apr
14
comment How can I cascade changes from one aggregate root to another?
This sounds like a description of your attempted solution to model the problem, but without any description about the problem itself. See What is the XY problem?
Apr
14
revised Principle of least astonishment (POLA) and interfaces
added 16 characters in body
Apr
14
answered Principle of least astonishment (POLA) and interfaces
Apr
14
comment Principle of least astonishment (POLA) and interfaces
Related: programmers.stackexchange.com/questions/187457/…
1 2 3 4 5