Recent articles, page #2
Personal naming and style convention
General observations
It always surprised me how little time developers spend considering and discussing naming conventions. An explanation of why it’s that way from a typical developer would probably be:
The way we name things should be clear right from the code.
for a good project and
It’s too late to change something.
for a bad one.
The counterargument to the second one is easy – at such state you probably will not make the project much worse in terms of structure and style – regardless of what structure and style do you use. So just make places that you work with as comfortable and organized as possible. Once I encountered a project with almost flat structure – it had three or four poorly filled folders and all the other code files piled in the root of the project (the code itself had similar issues). IMO, in such cases you should just apply a proper style – at least for your specific tasks – as arguments like “we should keep the existing convention [even if it’s pointless]” or “what if a new developer does not know what a presentation layer [or any other common term] is” does not sound reasonable to me.
The first one could really be true – at least that’s our goal – especially when a team spent some time properly setting up code analysis tools like StyleCop or even using Code Contracts – some decent standards can be achieved. But most of the times – implementing features is more valuable and leaving opportunities for hacks is more convenient.
Everybody’s probably heard of how naming things is one of the hardest things. On top of that – while code effectively is a text, it’s perceived more like a scheme.
... read moreMultiple inheritance of DTOs would be a good idea
Let’s start from afar
C# 8 is to have default interface implementations as one of it’s new features (as it’s described e.g. here).
This feature is described as reasonable and even exciting (as most of the features shipped with every new C# version IMO). The feature reminds good old .h C++ files (with the ability to either have an implementation or not) – everything new is well-forgotten old indeed.
The feature is also frighteningly reminiscent of another rather arguable C++ concept – the concept of multiple inheritance and questions like “what implementation will it choose”. It’s really a bit disturbing as it leads to one of the following:
- unclearness, ambiguity, and obligation to know more compiler implementation specifics (which could be interesting, but yet redundant);
- cumbersome syntax – e.g. an obligation to specify a concrete interface to take a method signature (with implementation) from.
Anyway – time will tell.
And why I’m telling you all this? Because I think there is a reasonable application for multiple inheritance in modern languages (especially back-end ones).
... read moreWhen dynamic typing is better than static
General observations
The “static vs. dynamic typing” confrontation is a rather long going one. More to that – unlike many other computer science related disputes – this one goes not only in academia, but also with the real-worldTM projects too (e.g. Node.js vs. ASP.NET for back-end solutions).
The main arguments in this controversy are:
You can utilize refactoring tools, IDE features, etc.
for static typing (e.g. C#); and
It’s easier to learn and to program on it.
for dynamic (e.g. JavaScript).
Which sound to me more like
I’m used to it.
and
I’m used to it.
respectively.
... read more