Talk:Coding standard

Indentation

What does it mean Use 4 character tabs for indentation and ensure that your editor is not converting tabs to spaces.?

If my editor doesn't change tabs to spaces, what's the difference whether they are shown in my editor as 4, 8 or 13 spaces?

Tharkang Varayez 09:18, 8 January 2007 (PST)

Non-code-structure spacing. Consider:

         func_call(one_param, two_param, three_param,
                   four_param, five_param, six_param);

The indent under func_call could be either ten spaces, or two tabs and two spaces. --Carnildo Greenacre 21:33, 10 January 2007 (PST)

OpenBSD and other os's?

The coding standard says LL_WINDOWS, LL_DARWIN, LL_LINUX are the only acceptable ifdef items. I have a diff that makes OpenBSD work, and sofar I've used __OpenBSD__ because c or c++ compilers on OpenBSD always define this. What does this mean for other operating systems as well? Can the coding standard be made more flexible in this regard? I know I could change it, but I'd rather get some idea that I'm changing it to say the desired thing from Linden Lab's point of view.

--Trek Houston 02:27, 20 January 2007

---

I have two comments on this issue.

• I don't like seeing #ifdef __OpenBSD__ in the viewer source files. If you need to put something specific to OpenBSD systems, you should create a macro LL_OPENBSD and #ifdef against it, and control the LL_OPENBSD macro by the building system (i.e., SConstruct.)
• I believe the reason Lindens say LL_WINDOWS, LL_DARWIN, and LL_LINUX are the only choise is that Windows, MacOSX, and Linux are the only platform they are developping against in-house. There are no reason you can add macros for other platforms. However, I'm afraid the flooding of the macros for minor variations; if LL_FREEBSD, LL_OPENBSD, and LL_NETBSD were defined, they would almost always #ifdef the same thing. Or, I don't want to see LL_OPENBSD3, LL_OPENBSD4, LL_OPENBSD4_1, LL_OPENBSD4_2, etc. It means someone (e.g., Rob Linden?) should control the creation of such macros by the open source community.

--Alissa Sabre 21:28, 23 June 2007 (PDT)

Name for typedef

I found there are no naming convention defined for (no enum) typedef's in Coding standard#Naming Convention. Grep'ing the source revealed that there are six conventions co-exist in the current source files:

• All lowercase "_"-separated words. E.g., data_map, joint_map.
• All lowercase "_"-separated words with a "_t" suffix. E.g., anim_map_t, undo_stack_t.
• Simple camelcase. E.g., KeyVector, ParameterizedMotion.
• "LL"-prefixed camelcase. E.g., LLXMLNodeList, LLPolyMeshSharedDataTable.
• "t"-prefixed camelcase (only seen in linden/indra/llxml/llcontrol.h). E.g., tPropertyChangedListIter, tListenerCallback.
• Unprefixed camelcase with "_t" suffix (only seen in linden/indra/llcharacter/llcharacter.h). E.g., VisualParamIndexMap_t, VisualParamNameMap_t.

Which convention should we follow for future coding?

-- Alissa Sabre 19:02, 11 September 2007 (PDT)