2012-03-06 8 views
7

Tengo un poco de experiencia en el desarrollo de iOS (más fondo de Java) y recientemente comencé a leer "Código limpio".Proyectos de iOS de código abierto para aprender las mejores prácticas de codificación

He notado que en mis proyectos iOS tengo muchos antipatrones.

recomendaciones

2 más populares que no siguen correctamente: métodos pequeñas y Clases pequeñas. Luego hice pequeñas investigaciones en GitHub y no encontré un proyecto que pueda usar como ejemplo/referencia para "Código limpio".

En la mayoría de los casos, ViewControllers tiene decenas de métodos Y tienen métodos ENORMES, como loadView donde creamos la jerarquía de vistas mediante programación.

Por ejemplo ejemplo aplicación de Facebook wishlist-mobile-sample tiene 1431 líneas de código en HomeViewController clase, y su loadView tiene más de 170 líneas de código.

¿Tiene enlaces a los proyectos que recomendaría como un buen ejemplo de codificación?

+0

tutoriales de verificación de http: //www.raywenderl ich.com –

+2

Gracias, pero he comprobado su ejemplo de rueda giratoria y el método 'drawWheel:' es enorme. Estoy buscando más para codificar las mejores prácticas pero usando el lenguaje Objective-C. – OgreSwamp

Respuesta

1

código de ejemplo de Apple es la mejor fuente para el aprendizaje de un código limpio .. proyectos de código abierto no se puede superar eso ..

+0

Creo que estamos hablando de diferentes "Código limpio". Si el código de Apple construye alguna jerarquía de vista, entonces sus métodos podrían ser más de 100 líneas de código. Ejemplo: el proyecto UICatalog, el método 'MainViewController'' - (void) viewDidLoad' tiene alrededor de 130 líneas de código. – OgreSwamp

2

me atrevo a discutir que tener todas las clases < 100 líneas de código es realmente una mejor codificación práctica ... Todo depende de para qué lo uses y de la importancia de tener una clase realmente limpia y general. Conozco algunos códigos que son más fáciles de leer con cientos de líneas en una clase que el código desordenado de la clase con súper mini clases, pero cientos de clases en su lugar ... Probablemente hay una razón por la que muchos proyectos tienen clases más grandes.

¿Y realmente crees que si la declaración es "una función debe tener un máximo de 100 líneas de código" que tener una función con 130 líneas ya califica para una codificación incorrecta?!?

Por cierto: La función viewDidLoad en la clase UICatalog de Apple cuenta con 42 líneas de código - el resto es blanco y comentarios - prefiero no dejar a los de su código con el fin de mantenerse por debajo de 100 líneas: -)

+0

Estamos hablando más aquí acerca de la declaración "la función debe tener un máximo de 20 líneas de código" y tener funciones con cientos de líneas de código. Su ejemplo es 0.3 veces la diferencia, en caso de que describa la diferencia, es de aproximadamente 10-20 veces. – OgreSwamp

+0

Bueno, mira mi adición: el código real es 42 líneas para el ejemplo de Apple.Objective C no es el lenguaje más eficiente en cuanto a espacio, tienes que introducir muchos espacios en blanco para mantenerlo legible, especialmente con los parámetros nombrados ... – TheEye

+0

Entiendo tu punto. De todos modos, estoy buscando ejemplos de código cercano al ideal :) que tiene funciones pequeñas que puedes leer fácilmente. Lo siento, pero necesito desplazarme por esta pantalla varias veces para leer todo el método. Y este ejemplo no tiene una estructura de vista complicada. Usa el enlace de muestra de Facebook en el cuerpo de la pregunta y verás de lo que estoy hablando. – OgreSwamp

1

No olvide que el propósito de los ejemplos que las publicaciones de Apple no son para mostrar las mejores prácticas en todo el código, sino para ilustrar elementos específicos. ¿Por qué molestarse en descomponer un método init en muchos trozos más pequeños (lo cual llevará tiempo hacerlo) cuando intenta demostrar cómo hacer una llamada de red asíncrona?

Al escribir su código, no hay nada de malo en escribir métodos enormes o grandes clases SI son apropiados para lo que está haciendo, correctamente comentado y no duplicar nada. Puede ser que eso es justo lo que tienes que hacer.

Como regla general, cuando escriba su código, simplemente piense en todo lo que está tratando de hacer y piense si puede dividirlo en trozos más pequeños. Piense en si usted tenía que hacer lo que sea que esté escribiendo el código para hacer y piense en cómo usted se acercaría a esa tarea.

Por ejemplo, es posible que desee escribir un método que inicialice la pantalla. Entonces, podrías escribir un gran método que hará todo.O bien, puede dividirla en al

[self initButtons]; 
[self initTextEntry]; 
[self initLabels]; 

Del mismo modo, en los initButtons, puede encontrarse con que, a continuación, escribir el mismo código de nuevo para crear y INIT los botones cuando resulta que la única cosa que cambia es la posición del botón y el selector al que llaman cuando se tocan. Entonces puede refactorizarlo

button1 = [self createButton:position callback:selector]; 
button2 = [self createButton:position2 callback:selector2]; 

Solo tome un enfoque iterativo de lo que está escribiendo. Escribe el código Una vez que tenga una función en funcionamiento, deténgase y retroceda, revise su código y vea dónde puede factorizar elementos, dónde tiene código común que ha agregado varias veces, etc. Utilice las herramientas de refactorización en XCode.

Desarrolle su propio estilo. Llegará con el tiempo y mientras más código escriba y refactorice, más fácil será ver cómo se pueden dividir las cosas desde el principio. Cuando pienso en algunos de los códigos que escribí hace 20 años, espero que hayan sido destruidos para que nunca vuelvan a ser vistos por un compilador. He trabajado en proyectos escritos por desarrolladores "profesionales" y existen métodos que son enormes. Por ejemplo, recientemente vi una que tenía 500 (!) Líneas de código de largo. Y con muy pocos comentarios.

Y recuerde que tener muchos métodos pequeños que combinen muy poco con una gran cantidad de clases (incluso si son clases pequeñas) también puede ser un antipatrón.

Cuestiones relacionadas