Difference between revisions of "Talk:Coding standard"
Trek Houston (talk | contribs) (OpenBSD and other os's vs coding standard...) |
Alissa Sabre (talk | contribs) |
||
| Line 15: | Line 15: | ||
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. | 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. | ||
--[[User:Trek Houston|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., {{User|Rob Linden}}?) should control the creation of such macros by the open source community. | |||
--[[User:Alissa Sabre|Alissa Sabre]] 21:28, 23 June 2007 (PDT) | |||
Revision as of 21:28, 23 June 2007
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)