# Sharing "Mobile App for Lottery Addiction"

Hello Community,

I just completed Dataquest’s guided project “Mobile App for Lottery Addiction”. Click here to link to the last page of the instructions.

I pretty much followed the guidelines, all fairly straightforward actually. Not looking for feedback on anything specific for this one, but any feedback is always welcome!

Here is my notebook ( a link to show this in Notebook viewer can be found at the bottom of this post):
MobileAppLotteryAddiction.ipynb (27.5 KB)

Best regards,
Jasper

Click here to view the jupyter notebook file in a new tab

3 Likes

First off congrats @jasperquak on completing your work. It takes some serious focus to do the same, and you’ve done it. (click on the triangle bullet points for the detail)

Presentation Style
• I see that you have an introduction, conclusion and multiple titles that explain the relative sections. I would usually name those sections as Introduction and Conclusion. Keeps it formal.
Coding Style
• I see that you have taken effort to define what each function does. When I started, I used to do the same. However, over time I learnt that there were standards to documentation. I recommend you check this for the same.

I have provided an example below of a function that I defined in an earlier project.

``````def camel_to_snake(a_column_name):

Convert column name from camel to snake case

Arg:
a_column_name(str): Column name to be converted from camel to snake case

Ret:
a_column_name(str): Column name in snake case

pos = 0
for letter in a_column_name:
if letter.isupper() == True:
pos = a_column_name.index(letter)
string1 = a_column_name[:pos]
string2 = a_column_name[pos:]
a_column_name = string1+"_"+string2
return (a_column_name.lower())
``````

It is good to put this in to practise now. It will pay off soon.

Bugs/Inaccuracies
• I could not find any issues with this regard.
Miscellaneous
• Nothing on this part.

I think you have done a great job and I hope to see this project after you’ve attempted the extra questions.

1 Like

Thank you @jesmaxavier for your feedback!

Regarding Coding Style. Thank you for the link and example. Good to stick to style guides indeed, and e.g. include the description of what a function does in the function itself rather than typing it above the function. (Although I would argue that that is more applicable for a live (and modular) application, and possibly less for a ‘notebook’ which you read from top to bottom.)

Regarding ‘Presentation Style’. Yes, in general I agree, applying it to most projects. (For this notebook I deliberately did not name the final section ‘Conclusion’ actually since I am not really ‘concluding’ anything based on observations or something.)

(Not meaning to say I disagree, just sharing why I did as I did.)

1 Like

@jasperquak, you are welcome!

Regarding this point, there is another use case where this kind of documentation could be helpful; when you are developing a lengthy notebook, and you want to recall a function that you have written many cells ago. Using `<function name>.__doc__` helps to recollect the parameters and default values of the function as below.

I have used it for this quite often and saves time from having to scroll up and down.

Makes sense.

1 Like

Interesting, with the function documentation! Didn’t know - thanks for sharing!

1 Like