Python Coding Conventions You Really Should Follow

In this video we learn about important Python conventions and guidelines to follow, defined in PEP8.
Oxylabs: oxylabs.io/pages/neuralnine?u...
Promo Code: NN25
◾◾◾◾◾◾◾◾◾◾◾◾◾◾◾◾◾
📚 Programming Books & Merch 📚
🐍 The Python Bible Book: www.neuralnine.com/books/
💻 The Algorithm Bible Book: www.neuralnine.com/books/
👕 Programming Merch: www.neuralnine.com/shop
🌐 Social Media & Contact 🌐
📱 Website: www.neuralnine.com/
📷 Instagram: / neuralnine
🐦 Twitter: / neuralnine
🤵 LinkedIn: / neuralnine
📁 GitHub: github.com/NeuralNine
🎙 Discord: / discord
🎵 Outro Music From: www.bensound.com/
Timestamps:
(0:00) Intro
(2:33) PEP8 Styling Guidelines
(5:03) Aesthetics & Layout
(14:39) Import Guidelines
(19:16) Commenting Guidelines
(23:22) Docstrings Conventions
(25:07) Naming Conventions
(31:54) General Recommendations
(33:52) Outro

[@BrannenTaylor]

Thanks for making the text larger - I like to watch with an iPad. Much easier to read and follow along.

[@yamildaboul6981]

Wow! Wusste nicht dass deine Muttersprache die deutsche war! Alles gute von einem argentinischen Fan! Danke für deine Zeit und Kenntnis 💪

[@nightline9868]

great video! Thanks man.

[@rachittanwar4685]

Like always, learnt something new from you. 😊

[@Daniel-gr8dm]

Very useful video, thanks you

[@JonathanAnima]

Thanks man !!!

[@corneliuslechner9263]

Great video!

[@ttrev007]

while i agree in professional code not stating the obvious is a no brainer, but i do think that beginner coders should go crazy with the inline comments. As a beginner coder i effectively cannot read code, looking back on code i have written i often have forgotten what i was doing, so having a translation to English of what the code is doing can be very helpful in learning how to read code. I know i will have to clean up my code if i ever publish it for others to use but i think it is super helpful to put in comments all over the place. It helps me learn. I worry not mentioning this might discourage noobs from doing something really helpful to the learning process. also remember to consider your reader. If you are writing code for programmers thats one thing but if you are expecting some with limited coding skills to read it you might want to put more documentation in then you might otherwise.

[@Mdroudian]

What's your view on the black formatting/style guide?

[@q.w.e.r.t.y]

thanks!

[@dave_by_day7632]

27:32 That's pascal case, not camel case

[@NishithSavla]

The not part is the opposite of what you said, the not should be after the is keyword as that improved readability. Also if not is put before x, it may confuse people to think of it like (not x) is None and that's misleading

You are right. The words "is not" together make a special operator. There the word "not" only makes a part of the "is not" operator. For the usual meaning of the keyword "not" you need to use parenthesis: "a is (not b)". For equality comparison we have "==" and "!=" operators for identity comparison we have "is" and "is not". Another multi-word operator is the membership operator "not in".

[@NishithSavla]

There shouldn't be whitespace in keyword arguments in function signature as per pep8

[@OleAmling]

Aren't these methods? 8:32

[@thepaulcraft957]

3:48 we in germany know how to make religions out of dump rules💪💪👊

[@Dalroc]

33:20 Uhhm you're literally saying the exact opposite of what PEP 8 does. Citing from PEP 8: Use is not operator rather than not ... is. While both expressions are functionally identical, the former is more readable and preferred: # Correct: if foo is not None: # Wrong: if not foo is None:

[@lennuard_6998]

second

[@joshuagage13]

Third

[@aarushkumar168]

First!!

[@cristobaljvp]

shortcut: just use black

[@dwaipayandas8692]

Thanks for the great content @NeuralNine🤟

[@rrahll]

thanks!