All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

T3Doc/TYPO3 Coding Guidelines

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Documentation Team (category DocTeam)

TYPO3 Coding Guidelines

Official document: TYPO3 Coding Guidelines

notice - Note

If you found a bug in the Coding Guidelines, please report it here. Thank you!

notice - This information is outdated

The following content on this page is outdated.

-- The author of the OpenOffice document is Kasper. This wiki page contains contributions from the documentation team and others.

New contribution: The Concept

This is a brainstorming/analyse-phase/document in progress in the moment, because it's just a collection from the discussion texts. Please contribute and add what is important. -- Kind regards, DocTeam, --Daniel Brüßler 23:29, 12 October 2006 (CEST)

Background story: Discussion driven by JoH aka Joey about concepts in TYPO3 projects.

Analysis - what is now

The fact is: just a small number of the concepts are _published_. Most are on paper or in the talk pages and newsgroups.

The reason is that almost always, the people who have the idea have to do the coding, too! So, it often makes not much sense to create documentation and big concepts before implementing it.

The coding guidelines for extension-writers have a section that documentation is _very_ important

The concepts have several places

  • The most agile and fast way: the concept is known by the people who follow the fire -- that means: in the talks, the texts of the newsgroups, in fast feedback, in the heads of one ore more people
  • Big long term projects:
  • Smaller projects: projects in the wiki : Projects -
  • Projects driven by long-term-teams: team-projects in the wiki Teams -


I think it's possible that all steps can just last 2-5 days.

This should be agile. (light-weighted time&energy, heavy-weight time&energy)

  1. Publish that there will be a new project, what the story is, when implementation starts
  2. Wish list collection (or some variation ideas of others)
  3. List of people who really want to do a part of the Todo list (who and what) and start of fund raising (the question is who supports what feature)
  4. Quick concept (collection of some texts, scan of a paper diagram, screen shots, links to video or mp3, notes of talks) with simple todo list
  5. Decisions what parts of the wish list the developer(s) want to do
  6. Better concept and functional prototype(s)
  7. Implementation in team or by just one person (!)
  8. Publication integration testing by all people/the team/just by one person, check of bugs and some problems

Conclusion: Wish list

  • check who would use the wiki - and under which requirements
  • check if a subst {{subst:p}} would have a good usability to create the whole page-structure
  • check if an extension at or a PDF somewhere would be better
  • check what points must be very lightweight in a developer-sight
  • check when I should ask for helpers
  • see Talk:Projects