Tag Archives: #mastery08

#mastery08 Python conventions (Zen of Python)

The zen of python is, according to long time Pythoneer Tim Peters, a set of rules you have to follow or at least to take into account while coding in python which are:

Source: https://www.python.org/dev/peps/pep-0020/

08 

1014

Gilberto Rogel García

The Zen of Python

Just did the mastery 08 which is an easteregg in python, quite interesting the way the creator describes it and kinda funny.

Video: https://www.youtube.com/watch?v=4vvz126C0JQ

1014 08

C++ coding conventions – Mastery08

¿Cómo lograr un buen código en c++ ?

Muchas veces al realizar un codigo nos preguntamos las maneras en que podemos resolverlos y podemos encontrar varias maneras, pero debemos tomar en cuenta que el codigo debe ser entendible tanto para nosotros como para las demas personas.

Hay que formarse el habito de tener las líneas con un espacio suficiente entre ellas, para que la lectura del mismo sea mas cómoda, y a la hora de estarlo revisando podamos encontrar los errores de una manera sencilla.

En 1999 el Zen de Python, creo una estructura eficiente para que los codigos fueran entendibles, aunque fue especialmente para los programadores de Python se pude aplicar a los demas lenguajes de programación, en nuestro caso en c++.

 

——————————————- The Zen of Python, by Tim Peters ————————————————–

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren’t special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one– and preferably only one –obvious way to do it.

Although that way may not be obvious at first unless you’re Dutch.

Now is better than never.

Although never is often better than *right* now.

If the implementation is hard to explain, it’s a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea — let’s do more of those!
 —————————————————————————————————————————————————-

Fuentes consultadas: http://recursospython.com/category/guias-y-manuales/page/3/

 

 

1017 08

 

Mastery 08

08 1017

Existen muchas maneras de realizar un codigo y no siempre para un problema en especifico solo existe una manera de resolverlo, pero, ¿Como realizar un codigo entendible para nosotros mismos y para los demas?, mcuhas veces como programadores empezamos a hacer un “relajo” en nuestro codigo ya que no tenemos una idea al principio si no que sobre la marcha las ideas van fluyendo y todo se nos cumplica al momento de acomodarlo (este es mi caso) por lo tanto debemos de saber como organizar de una manera correcta nuestros codigos.

Aun que nosotros estamos aprendiendo a programar en c++, existe un “codigo” (no de programacion, si no, para programar) por asi decirlo para poder realizar no solamente un codigo efectivo, si no, para hacer un codigo entendible y de calidad, este codigo fue diseñado princpalmente para los programadores de Python, por eso es llamado el Zen de Python, pero creo conveniente que sea tomado igual por los programadores de c++ para un aumento drastico en la calidad de los programas; a continuacion escribire el Zen de Python, hecho por Tim Peters hacia el remoto año de 1999.

M08 – C++ Coding Conventios

Hey everybody!

In this post, we will talk about coding conventions: a bunch of (breakable) rules to write the best code you can write.

I found this page, with some of them and I found it very interesting. I hope you enjoy both!

http://geosoft.no/development/cppstyle.html

https://www.dropbox.com/s/4xnytr2qnxzhtzu/M08%20-%20Coding%20Conventions.mp4?dl=0

Basic types and their use in Python

                                                                                                                       @PablO_CVi

Types are a category for things within Python with which Python will work. Types are:

 

integers 
Whole numbers from negative infinity to infinity, such as 1, 0, -5, etc.
float 
Short for “floating point number,” any rational number, usually used with decimals such as 2.8 or 3.14159.
strings 
A set of letters, numbers, or other characters.
tuples 
A list with a fixed number of elements. ie x=(1,2,3) parentheses makes it a tuple.
lists 
A list without a fixed number of elements. ie x=[1,2,3] note the square brackets, a list
dictionaries 
A type with multiple elements i.e. x = {1: ‘a’,’b’: 2,3: 3} where you address the elements with, e.g., a text..

Taken from: http://en.wikiversity.org/wiki/Python/Basic_data_types

Python conventions (Zen of Python)

                                                                                                                       @PablO_CVi

 Many years ago a Pythoneer Tim Peters succinctly channels the BDFL’s guiding principles for Python’s design into 20 aphorisms, only 19 of which have been written down.      

        “Beautiful is better than ugly.    

        Explicit is better than implicit.    

        Simple is better than complex.    

        Complex is better than complicated.    

        Flat is better than nested.    

        Sparse is better than dense.    

        Readability counts.    

        Special cases aren’t special enough to break the rules.    

        Although practicality beats purity.    

        Errors should never pass silently.    

        Unless explicitly silenced.    

        In the face of ambiguity, refuse the temptation to guess.    

        There should be one– and preferably only one –obvious way to do it.    

        Although that way may not be obvious at first unless you’re Dutch.    

        Now is better than never.     Although never is often better than *right* now.    

        If the implementation is hard to explain, it’s a bad idea.    

        If the implementation is easy to explain, it may be a good idea.     

        Namespaces are one honking great idea — let’s do more of those!”(2004, p1).

Recuperado de: https://www.python.org/dev/peps/pep-0020/

 

 

#Mastery08 #TC1014 #LaNieveDeColimaExploto #PenguinLove #video

Zen of python 

Espero que les guste suscribanse y denle like

http://youtu.be/CcrEN5GoB7A?hd=1

Learn To Program 2015-04-24 17:49:00

Mastery08

Long time Pythoneer Tim Peters succinctly channels the BDFL’s guiding principles for Python’s design into 20 aphorisms, only 19 of which have been written down.

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!

Tim Peters

**********************
Programa hecho en Python:
**********************
https://github.com/A01630323/Learn-To-Program/blob/master/Mastery08.py

Learn To Program 2015-04-24 17:49:00

Mastery08

Long time Pythoneer Tim Peters succinctly channels the BDFL’s guiding principles for Python’s design into 20 aphorisms, only 19 of which have been written down.

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!

Tim Peters

**********************
Programa hecho en Python:
**********************
https://github.com/A01630323/Learn-To-Program/blob/master/Mastery08.py