code review based on what I learned from D

[Rikki Cattermole via Digitalmars-d-learn]

On 5/07/2015 6:53 p.m., Szabo Bogdan wrote:
> Hi,
>
> Recently while I was reviewing some swift code, a colleague left me the
> impression that I am the one with the bad habits and these were learned
> while coding in D. I still think that I proposed some changes to avoid
> some bugs but I was told that I am focusing on defensive programming and
> that is a bad thing.
>
> The first issue that I raised was this one:
>
> func renderCell(item: AnyObject, index: Int) {
> -        fatalError("renderCell has not been implemented")
> +
> }
>
> where I proposed to make that method abstract or let's not remove the
> fatalError message because this method it should be never called.
>
> The second issue was this:
>
> +    init(dataSource: WUPTableDataSource) {
> +
> +        self.dataSource = dataSource
> +        dataSource.tableView = tableView
>
> where I asked what happens if someone passes a dataSource that has a
> tableView set. I this class, there were set some events bind to the view
> and it was unclear what happened in that case and I proposed to add an
> assert to check if dataSource.tableView is not set before we set it.
>
> For both of these issues I was told that swift is not Java and if the
> situations that I described happens, you don't want to crash the user
> app, because this will make the user unhappy.
>
> Those things are for me, good habits that I do when I am programming
> with D. What do you think? and if I had bad ideas with those issues,
> what I can do to improve my skills?
>
> thanks,
> Bogdan

Your collages are arguing that if they exist, they could be called and 
make program fail. Which is a valid point of view.

However, from a development point of view, you kinda want to know if 
they are being called.

I think you are arguing for slightly something different then to what 
you think.
I recommend arguing for a function that allows you to log during 
development in some form (maybe exceptions) to find where code paths are 
being used where you did not expect.

Another thought is defensive programming is _not_ a bad thing. Its an 
amazing thing really. It's great to do, to make sure an application does 
not get into an erroneous state. But you know what also is great? 
Failing gracefully. Not something most developers do.

Anyway just my thoughts on it.