Sugar Developer Blog Style Guide

Document created by Alex Nassi Employee on Jun 23, 2016Last modified by Alex Nassi Employee on Nov 21, 2017
Version 3Show Document
  • View in full screen mode

Who is our audience?

Our primary audience that we want to reach are programmers, developers, and solutions architects who build solutions on Sugar 7 or integrate applications with Sugar 7.  This includes people who may be considering building solutions with Sugar 7 as well.

Secondary audiences are anyone involved in the wider Sugar community as well as people involved in IT, SaaS, or Enterprise business application industry.

This blog sees significant traffic from all over the world, all day long, during the work week.  The assumption is that the main consumers of our content are people sitting in their office browsing for latest events in Sugar development community as well as learning from other’s experiences in building solutions on Sugar 7.


Trusted experts.  Authoritative.  Informative.

There are other blogs on Sugar 7 development and other places to get answers to questions (such as community forums).  When people are coming to the blog they are looking to see Sugar’s authoritative voice.  Since the Sugar Developer Guide is the authoritative reference, then the Sugar Developer Blog’s technical content should be focused on authoritative best practices.  All code examples need to be fully functioning.  Code needs to be clean, fully documented, and at least defensible against criticism.


Sugar 7 Development Best Practices

Upcoming SugarCRM or SugarCRM Partner sponsored events

Sugar product information including release announcements, sneak peaks, or advance notices.

Guest posts containing technical content or promoting events from Sugar Customers, Partners.

Preferred Terminology

“Sugar” is the name of the product.  For example, “Sugar 7.5” not “SugarCRM 7.5”.

“SugarCRM” is the name of the company.  For example, “I work for SugarCRM” not “I work for Sugar”.

“Sugar Developers” are the people who develop on top of the Sugar product.  For example, “Sugar Developers who work for SugarCRM Partners need to be certified!”

“SugarCRM Mobile” is the name of the latest mobile application offering provided by SugarCRM that is compatible with Sugar 7.


Do keep a professional tone.

Do use paragraphs.

Do try to be concise but not at the expense of clarity.

Do place significant code samples into Gists.  Smaller code samples can be placed in Preformatted blocks.

Do mention the specific versions of Sugar or other software you are using.

Do provide compelling technical content about Sugar 7.

Do provide specific advice.  Tell your audience what they need to be doing, not just how you did it.

Do color your comments with personal experience.

Do call out best practices using blockquotes in order to highlight them for readers.

If the post is a response to a question, Do paraphrase the question in a blockquote above the fold of the post.

Do use bold text to highlight file paths or menu paths within instructions.

Do provide clearly numbered and labeled steps in Heading 2 style for instructional posts.

Do provide screenshot of final outcome of an instruction approach when appropriate.


Do not use H1 (Heading 1) elements.  In general, there should only be one H1 header in page which is reserved for blog post’s title.

Do not mention competitor products or services.

Do not plagiarize content.  Always provide proper attribution when your work is not entirely original.

Do not disparage anybody or anything.  This blog represents Sugar Engineering and the Sugar Developer community which is diverse in opinions, people, and past experiences.

Do not create new blog posts about Sugar 6.x or Sugar Community Edition

Want to contribute?

Click here to submit your blog for review and moderation.