MojoMojo development best practices
Below are the currently agreed-upon development practices for writing MojoMojo code. Discussion are welcome at discussion.
In Perl code, abide by perlstyle: use 4-space indentation, no tabs, spaces around operators etc. Really read
In Template::Toolkit code, use 4-space indentation for HTML code, and 2-space indentation for TT code. See rationale and examples at Indenting TT and HTML.
Line length is 120 characters per line (this happens to also be about how many characters fit in the GitHub UI at 100% zoom). Nobody really uses 80-character lines any more, many existing lines are already longer than 80 characters (and perltidy wraps them horrendously), and we don't print out code. If you are using Perl::Tidy to automatically format your code, you can set a different line length via:
perltidy --perl-best-practices -l=115
However, in the tradition of Catalyst code, use of perltidy is discouraged. For example, Catalyst::Stats does not vertically align on '.', and Catalyst::Test does not wrap at anything less than 112 characters.
Marcus' last word on this is "In general I want catalyst style code, if people run perltidy on stuff they write, I don't mind. I just want a readable codebase that is easy to contribute to." Jasa SEO Jasa SEO Murah Sepatu Online Toko Sepatu Online Sepatu Sepatu Safety Cheapes Hostgator Coupon Link Booking Televisori offerte Notebook Offerte Govr Edo Ziedo Portatile Apple RDAnet Lorks Karikatur tertinggal Bisnis UKM Bisnis Modal Kecil Iklan Baris Jasa SEO Murah SEO Indonesia Konsultan SEO SEO Belajar SEO Penumbuh Rambut Kursus SEO Jam Tangan Casio Grosir Baju Terbaru Bisnis Online Belajar SEO Kerupuk Social Bookmark Kumpulan Puisi
Development best practices
- All testable functions should have tests
- Every module and function should have POD documentation
- HTML output should be XHTML 1.0 Strict
- CSS 2.
- We use Test::More and Test::Differences. The latter is very handy for diffing long outputs side-by-side, such as full formatter outputs from
- If you write failing tests for upcoming features (TDD), put them in Test::More TODO sections.
- Do not put failing regression tests in TODO sections just to have tests pass and ship. Work on fixing the code to pass the tests.
- WebGUI development best practices - a competing Perl-based CMS from which some of these guidelines were inspired
Showing changes from previous revision.