www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - code review based on what I learned from D

reply "Szabo Bogdan" <szabobogdan yahoo.com> writes:
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
Jul 04 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Jul 05 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 05 Jul 2015 19:01:59 +1200, Rikki Cattermole wrote:


 Failing gracefully. Not something most developers do.


usually that is not related. i mean that if program entered invalid=20
state, it may be too late to save user data. it may be even undesirable=20
to do so, as the data may be already corrupted.

what the good program should do (i think) is storing "working log", so if=20
it crashed, the log can be replayed from the last saved state, restoring=20
all the work. maybe with the option that allows the log to be replayed=20
partially, to avoid endless crashes.

besides, it will be possible to send the document and the log to=20
developers, so they can reproduce the exact bug.=
Jul 05 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 5/07/2015 9:37 p.m., ketmar wrote:

 On Sun, 05 Jul 2015 19:01:59 +1200, Rikki Cattermole wrote:


 Failing gracefully. Not something most developers do.


 usually that is not related. i mean that if program entered invalid
 state, it may be too late to save user data. it may be even undesirable
 to do so, as the data may be already corrupted.

 what the good program should do (i think) is storing "working log", so if
 it crashed, the log can be replayed from the last saved state, restoring
 all the work. maybe with the option that allows the log to be replayed
 partially, to avoid endless crashes.

 besides, it will be possible to send the document and the log to
 developers, so they can reproduce the exact bug.


Of course of course.
Valid options in failing gracefully include resetting the data and 
informing the user. Also giving them an option to send a bug report to 
the devs.
Point being, having it just fail on start each time is not a valid end 
result or something else awful.
Jul 05 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 05 Jul 2015 21:39:23 +1200, Rikki Cattermole wrote:


 Of course of course.
 Valid options in failing gracefully include resetting the data and
 informing the user. Also giving them an option to send a bug report to
 the devs.
 Point being, having it just fail on start each time is not a valid end
 result or something else awful.


ah, i see and i fully agree.=
Jul 05 2015
parent "Bogdan" <szabobogdan yahoo.com> writes:
On Sunday, 5 July 2015 at 09:46:19 UTC, ketmar wrote:

 On Sun, 05 Jul 2015 21:39:23 +1200, Rikki Cattermole wrote:


 Of course of course.
 Valid options in failing gracefully include resetting the data 
 and
 informing the user. Also giving them an option to send a bug 
 report to
 the devs.
 Point being, having it just fail on start each time is not a 
 valid end
 result or something else awful.


 ah, i see and i fully agree.


I think that if you really are scared if your installed app will 
crash because of some assert that you wrote, it means that you 
are not confident enough with your coding skills. I use asserts 
to remember me something that I am not allowed to do.

As a developer sometimes I say that I will do "this" and I will 
remember to use it like "that" and this is almost never happens. 
When you work in a big team, this NEVER happens and not because 
people are evil, because we forget things, and it's easy to make 
mistakes.

I use asserts to fail quick, during development. If you are 
afraid to make a program that not crashes you should not be a 
programmer. I bet that everyone would prefer to  have a program 
that crash for known reasons instead from some unknown, strange, 
science-fiction bug.

And if you are really afraid of asserts in your code you can 
disable them for the release build, but I personally would not do 
that.

Bogdan
Jul 06 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 05 Jul 2015 06:53:34 +0000, Szabo Bogdan wrote:


 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.


i completely agree. it's way better to keep going and silently corrupt=20
user data. i mean, well, nobody cares about corrupted data if a program=20
is not crashed, right? happy users with invalid data will buy version 2,=20
for sure.=
Jul 05 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 5/07/2015 9:32 p.m., ketmar wrote:

 On Sun, 05 Jul 2015 06:53:34 +0000, Szabo Bogdan wrote:


 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.


 i completely agree. it's way better to keep going and silently corrupt
 user data. i mean, well, nobody cares about corrupted data if a program
 is not crashed, right? happy users with invalid data will buy version 2,
 for sure.


Ahhh sarcastic ketmar, one of the best ketmar's selfs. Welcome back.
It was what I was saying anyway :)
Jul 05 2015
prev sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Sunday, 5 July 2015 at 06:53:36 UTC, Szabo Bogdan wrote:

 "you don't want to crash the user app, because this will make 
 the user unhappy."



This type reasoning is always flawed. It's like saying that the 
Earth is flat.

http://p0nce.github.io/d-idioms/#Unrecoverable-vs-recoverable-errors
Jul 06 2015