great_code
所属分类:自动编程
开发工具:Others
文件大小:13KB
下载次数:0
上传日期:2016-01-23 07:06:50
上 传 者:
sh-1993
说明: 年轻人和老年人的最佳编程实践。你的代码审查伙伴。
(Best programming practices for young and old. Your code review buddy.)
文件列表:
code_examples (0, 2016-01-23)
code_examples\general_programming (0, 2016-01-23)
code_examples\general_programming\.keep (0, 2016-01-23)
code_examples\javascript (0, 2016-01-23)
code_examples\javascript\.keep (0, 2016-01-23)
code_examples\rails (0, 2016-01-23)
code_examples\rails\controller_tests (0, 2016-01-23)
code_examples\rails\controller_tests\.keep (0, 2016-01-23)
code_examples\rails\controllers (0, 2016-01-23)
code_examples\rails\controllers\.keep (0, 2016-01-23)
code_examples\rails\engines (0, 2016-01-23)
code_examples\rails\engines\.keep (0, 2016-01-23)
code_examples\rails\general (0, 2016-01-23)
code_examples\rails\general\.keep (0, 2016-01-23)
code_examples\rails\helper_tests (0, 2016-01-23)
code_examples\rails\helper_tests\.keep (0, 2016-01-23)
code_examples\rails\helpers (0, 2016-01-23)
code_examples\rails\helpers\.keep (0, 2016-01-23)
code_examples\rails\models (0, 2016-01-23)
code_examples\rails\models\.keep (0, 2016-01-23)
code_examples\rails\partials (0, 2016-01-23)
code_examples\rails\partials\.keep (0, 2016-01-23)
code_examples\rails\templates (0, 2016-01-23)
code_examples\rails\templates\.keep (0, 2016-01-23)
code_examples\rails\tests (0, 2016-01-23)
code_examples\rails\tests\.keep (0, 2016-01-23)
code_examples\ruby (0, 2016-01-23)
code_examples\ruby\classes (0, 2016-01-23)
code_examples\ruby\classes\.keep (0, 2016-01-23)
code_examples\ruby\gems (0, 2016-01-23)
code_examples\ruby\gems\.keep (0, 2016-01-23)
code_examples\ruby\general (0, 2016-01-23)
code_examples\ruby\general\.keep (0, 2016-01-23)
code_examples\ruby\methods (0, 2016-01-23)
code_examples\ruby\methods\.keep (0, 2016-01-23)
code_examples\ruby\modules (0, 2016-01-23)
code_examples\ruby\modules\.keep (0, 2016-01-23)
code_examples\ruby\naming (0, 2016-01-23)
... ...
**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)*
- [General Programming](#general-programming)
- [Javascript](#javascript)
- [Ruby](#ruby)
- [General](#general)
- [Naming](#naming)
- [Methods](#methods)
- [Objects](#objects)
- [Classes](#classes)
- [Modules](#modules)
- [Tests](#tests)
- [Gems](#gems)
- [Rails](#rails)
- [General](#general-1)
- [Tests](#tests-1)
- [Controllers](#controllers)
- [Controller tests](#controller-tests)
- [Helpers](#helpers)
- [Helper tests](#helper-tests)
- [Templates](#templates)
- [Partials](#partials)
- [Models](#models)
- [Engines](#engines)
***
# General Programming
- Organize code on filesystem in a meaningful manner
- Declare dependencies
- Prefer additive synthesis over subtractive synthesis
- Follow [SOLID](http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29), [DRY](http://en.wikipedia.org/wiki/Don%27t_repeat_yourself), and the [Law of Demeter](http://en.wikipedia.org/wiki/Law_of_Demeter)
- Avoid [Connascence](http://en.wikipedia.org/wiki/Connascence_(computer_programming))
- [Wrap data in objects and provide methods to interact with the data on the class of the object](http://en.wikipedia.org/wiki/Object-oriented_programming)
- Use comments
- Use local variables to improve readability
- Delete commented-out code
- Delete unused code
- Test your code
- Address deprecation warnings; don't add new ones
- Mind code line lengths; use whitespace
- Make [small things](https://www.youtube.com/watch?v=8bZh5LMaSmE) (classes, modules, objects, subsystems, etc.) that have [specific responsibilities](http://en.wikipedia.org/wiki/Single_responsibility_principle)
# Javascript
- Understand the integral types
- Understand prototypal inheritance
- Use modules
- Avoid globals
# Ruby
## General
- Understand the [Ruby Object model](https://blog.jcoglan.com/2013/05/08/how-ruby-method-dispatch-works/)
- Understand Ruby autoloading
- Avoid globals ($global_var, referencing external constants, ENV)
- Avoid dangling references
- Avoid opening classes/modules
- Avoid using `eval`
- Prefer composing objects over using mixins
- Avoid putting methods in base classes that only apply to some-but-not-all subclasses.
- Avoid using `alias`, `alias_method` or `alias_method_chain` [:microphone:](https://github.com/appfolio/great_code/issues/4)
- Avoid using keywords or common methods for names (e.g. `send`, `include`, etc.)
- Prefer variables with the smallest scope (local variables, instance variables, class instance variables, class variables)
- Avoid inverted `if`/`unless` statements with complicated expressions
- Avoid `unless` statements with more than one terminal in the expression
- Prefer `if`/`unless` statements over ternaries
- Avoid using `send`, `instance_variable_set` and `instance_variable_get`
- Memoize only when necessary
- Only use the global resolution operator (`::`) when necessary
- Access class instance methods via the dot (`.`) operator instead of the double-colon (`::`) operator
- Avoid using `respond_to?` to check for `nil?`
- Prefer methods over blocks/procs/lambdas
- Prefer using parenthesis for method invocations
- Avoid uses of `respond_to?` and `method_defined?`
- Prefer `respond_to?` over `obj.class.method_defined?`
- Raise well-named, descriptive exceptions; don't call `raise` without an exception class
- Class or module definitions nested in namespacing modules should use the long format like so:
```ruby
module SomeNamespace
class MyClass
```
as opposed to:
```ruby
class SomeNamespace::MyClass
```
## Naming
- Use meaningful, intention-revealing names.
- Avoid context-less prefixes/suffixes (Helper/helper, Methods, Mixin, Data/data, etc.)
## Methods
- Choose good names
- Should be small
- Use `?` suffix for queries
- Generally, don't use `!` suffix; only use it according to a prevailing convention
- Prefer keyword args over options hashes
- Do not modify input parameters
- Wrap exceptions
- Use required parameters by default; only provide defaults when necessary
## Objects
- Prefer instances over classes and modules
- Use objects to encapsulate state
- Prefer local variables over instance variables
- Instance variables should hold state with the same life span as the object (see [here](http://programmers.stackexchange.com/questions/214851/ruby-when-to-use-instance-variables-vs-parameters-between-methods) for an explanation).
- Don't use instance variables to pass data across methods
- Only provide accessors when necessary
- Inject dependencies
## Classes
- Choose good names
- Prefer [composition over inheritance](http://engineering.appfolio.com/2014/08/20/a-composition-regarding-inheritance/)
- Specify method visibility
- Default to using `private`, not `protected`
- [Use `protected` only when you need to; you most likely don't need to](https://docs.google.com/a/appfolio.com/presentation/d/1U9UiDv6dHSNhVYzVsu7a8eKbC2xEb93OBqTbDVWLE6o/edit?usp=sharing)
- Avoid "class methods"
- Put nested classes in separate files
- Extract complex private/protected methods into other classes
## Modules
- Use [`ActiveSupport::Concern`](http://engineering.appfolio.com/2013/06/17/ruby-mixins-activesupportconcern/) only when you need to
- Create single purpose modules: used as a mixin, used for namespacing, used for holding static methods, defining constants, etc.
## Tests
- Test every code path
- Only test private/protected methods when complex
- Prefer minitest assertions over test-unit
- Test behaviour over implementation
- Avoid computing expected results
## Gems
- Use [semantic versioning](http://semver.org/)
- Require dependencies in manifest
- Use versioned dependencies
- Test the gem
- Use [Appraisals](https://github.com/thoughtbot/appraisal)
- Provide documentation
# Rails
## General
- Understand [Rails autoloading](http://guides.rubyonrails.org/autoloading_and_reloading_constants.html)
- [Avoid Rails' autoloading where possible](loading_files.md)
- Prefer the Rails Way unless you have a good reason not to
- Prefer Ruby's `nil?` over ActiveSupport's `present?`/`blank?`
- Generally avoid and only use `try`/`present?`/`blank?` when appropriate
## Tests
- Don't override setup/teardown
- Use setup/teardown block helpers
- Setup/teardown hooks should only do things common to all tests in the TestCase class
- Use private methods to denote "non test" methods
- Nest helper classes/module definitions under the TestCase class
- Test file organization should mirror file organization of code under test
## Controllers
- Only use their own helper / Never use another controller's helper
- Never use the `helper` method
- Use [form objects](http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/#form-objects)
- Use services for business logic
- Verify parameters
- Use the appropriate HTTP status code
- Prefer "passing" one instance/local variable to render views
## Controller tests
- Rails Way: only one controller action per test
- Use the correct action method (`get`, `post`, `xhr`, etc.)
- Assert on HTTP response
- Avoid using `assigns`
- Assert on effect of controller action
## Helpers
- Generally prefer presenters, view models or decorators over helpers
- [Do not include helpers of other controllers](https://groups.google.com/a/appfolio.com/forum/?hl=en#!searchin/dev.list/God$20Helpers/dev.list/hKPxbAMuGDw/LEv_jRAC-tQJ)
- Include mixins for all dependencies
- Do not depend on controller-helper stack
- Do not act on instance variables
## Helper tests
- Should not require a specific controller context
- Use `view.` handle
- Avoid using `instance_variable_set`
## Templates
- Do not render templates or partials of other controllers
- Do not use instance variables
- Use partials
- Use view models
- No logic
## Partials
- Same as templates
- Partials that can be rendered by more than one controller go in views/shared
## Models
- Use services for business logic
- Avoid ActiveRecord callbacks
- Avoid overriding common `ActiveRecord::Base` methods (`initialize`, `save`/`save!`, `create`/`create!`, etc.)
- Avoid using `default_scope`
- Avoid using `update_attribute`
- Avoid using [`update_columns` and `update_column`](https://cbabhusal.wordpress.com/2014/10/08/different-between-update-update_columns-update_column-update_attributes-assign_attributes/)
- Prefer and default to using validations
- Prefer and default to using `!`-methods that raise exceptions when validations fail
- Handle the return value when using non-`!`-methods (e.g. `save` and `create`)
## Engines
- Use injections
- Make injections explicit
- Provide injection defaults
- Avoid use of `main_app` view route proxy
- Don't provide, use or reference an "Application" controller, helper, JS, CSS, etc.
近期下载者:
相关文件:
收藏者: