# materialNonLinearity.jl ###### tags: `Entregable 8` ### Revisar dependencias - (resuelto) Actual: ```julia [deps] BenchmarkTools = "6e4b80f9-dd63-53aa-95a3-0cdb28fa8baf" Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4" DocumenterTools = "35a29f4d-8980-5a13-9543-d66fff28ecb8" FastGaussQuadrature = "442a2c76-b920-505d-bb47-c5924d526838" LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e" Plots = "91a5bcdd-55d7-5caf-9e0b-520d859cae80" Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40" ``` Recomendado: ```julia [deps] DocumenterTools = "35a29f4d-8980-5a13-9543-d66fff28ecb8" FastGaussQuadrature = "442a2c76-b920-505d-bb47-c5924d526838" LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e" Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40" ``` Razon: Una dependencia de un proyecto es otra libreria que es imprescindible cargar para utilizar dicho proyecto. Normalmente, ninguno entre `BenchmarkTools`, `Documenter` y `Plots` es una dependencia. Lo normal es agregar dichos paquetes al entorno global (o al entorno de trabajo, pero como son paquetes usados en casi cualquier proyecto, recomendamos agregarlos al entorno global). Observar que si tenes al paquete `Foo` en el entorno global, Julia lo carga con `using Foo` incluso si tenes activado un entorno local. ### Convencion de nombres - (resuelto) Recomendamos leer el siguiente link y utilizar dicha nomenclatura estandard para nombres de metodos y structs: https://docs.julialang.org/en/v1/manual/style-guide/#Use-naming-conventions-consistent-with-Julia-base/ De no seguir esa regla resulta muy confuso la lectura del codigo (para alguien que sabe leer Julia). Por ejemplo, no se sabe si `materialModel` se trata de un struct o de un metodo solo con el nombre, mientras que: - `MaterialModel`: es un nombre de struct (o constructor de struct) - `material_model`: es un nombre de metodo ### Refactoring - (resuelto) La organizacion 1 archivo - 1 funcion no es recomendable. Pensar que el nombre de la funcion es un detalle de la implementacion (en el sentido de que puede cambiar en cualquier moment), mientras que las funcionalidades son mucho mas estaticas, digamos, funciones relacionadas a grids, vamos a encontrarlas en un archivo llamado `grids.jl`, etc. Por tanto, sugerimos pensar como organizar las funciones del proyecto en torno a las distintas componentes del problema. Digamos, - geometria, - otras caracteristicas fisicas del modelado, - metodos iterativos, - representacion de la solucion, - funciones utilitarias, etc. Funciones de utilidad, por ejemplo `nodes2dofs` se pueden organizar en un archivo `utils.jl`, aunque en lo posible se debe colocar cada funcion cerca de los structs a los que aplica, o en un lugar conceptualmente razonable. Notese que despues de este refactoring se tendra un menor numero de archivos que los actuales. ### Dudas - (resuelto) * Me resulta más directo y visible tener cada función en un archivo separado. Colocar las funciones en un solo archivo que utilidad tiene además de disminuir la cantidad?