[NOPE] Forming code style standard guidelines

You newer know what might be liked

Moderators: elder, overseer, arch, avatar, creator

Post Reply
User avatar
ilmarinen
Posts: 275
Joined: 21 Mar 2019, 22:32

[NOPE] Forming code style standard guidelines

Post by ilmarinen » 14 Jul 2019, 07:20

You know it has to be done, in some way.

First thing I suggest just to pick most freequent appearance of one or another style for lexical unit.

Or we can vote on using pre-defined by someone else code style, such as:
  • “gnu”: The default style for GNU projects
  • “k&r”: What Kernighan and Ritchie, the authors of C used in their book
  • “bsd”: What BSD developers use, aka “Allman style” after Eric Allman.
  • “whitesmith”: Popularized by the examples that came with Whitesmiths C, an early commercial C compiler.
  • “stroustrup”: What Stroustrup, the author of C++ used in his book
  • “ellemtel”: Popular C++ coding standards as defined by “Programming in C++, Rules and Recommendations,” Erik Nyquist and Mats Henricson, Ellemtel
  • “linux”: What the Linux developers use for kernel development
  • “python”: What Python developers use for extension modules
Examples of corresponding styles are shown in this Wiki article.

On the question of tabs vs spaces spaces (gladly :P) have won, among current developers and in retrospective.
On the question of two vs four spaces four scapes (sadly) have won.
User avatar
ilmarinen
Posts: 275
Joined: 21 Mar 2019, 22:32

Re: Forming code style standard guidelines

Post by ilmarinen » 14 Jul 2019, 07:21

Instead of using poll I suggest we just talk.
I really don't care which style you pick up, because my editor is so superior to yours it reformats code style for me :P
lujke
Posts: 9
Joined: 22 Mar 2019, 06:38

Re: Forming code style standard guidelines

Post by lujke » 14 Jul 2019, 09:36

My cards on the table: I don't know any of those code styles, and I'm a bit daunted by the prospect of having to learn something new. I understand it's a reaonable enough idea, but my RL involves a lot of academic pressure at the moment, so my coding is a release valve: I don't want it to start feeling like work...
User avatar
ilmarinen
Posts: 275
Joined: 21 Mar 2019, 22:32

Re: Forming code style standard guidelines

Post by ilmarinen » 14 Jul 2019, 15:44

Its not going to be enforced... Besides, we have 4 million lines of code, that just impossible.
Just pick what you like most, mewbe, so others can suffer from your decision, and you'll be left to lizardy thingies?
nienne
Posts: 16
Joined: 04 Apr 2019, 00:46

Re: Forming code style standard guidelines

Post by nienne » 15 Jul 2019, 01:32

I am quite happy with spaces, and four of them :P

I tend to have a standard pattern but I know it doesn't match some others (eg/ Saide/Ares use quite different bracket placement). I didn't really think much beyond my own standard feeding my OCD, as per Lujke I didn't really know there's all these different "ways" or whatever. I think mine is one of the java/c++ ones. k&r maybe? Given I learned java coding first in school, that's probably why.
ramius
Posts: 2
Joined: 21 Jun 2019, 00:59

Re: Forming code style standard guidelines

Post by ramius » 15 Jul 2019, 02:19

So I'm not a real coder, just someone who reads code and sorta translates it for others. My question is this: Is there a mass bash script we can run to standardize all code and put it in a format where standardization is easier (cause if this guy did it, I should do it too)?
User avatar
ilmarinen
Posts: 275
Joined: 21 Mar 2019, 22:32

Re: Forming code style standard guidelines

Post by ilmarinen » 15 Jul 2019, 19:47

ramius wrote:
15 Jul 2019, 02:19
So I'm not a real coder[...]
I can do it for tabs vs spaces issue at least... For the other stuff like

Code: Select all

if(blep) {
    mlem;
}
vs

Code: Select all

if(blep)
{
    mlem;
}
its not that trivial.
User avatar
circe
Posts: 8
Joined: 09 Jul 2019, 01:22

Re: Forming code style standard guidelines

Post by circe » 24 Jul 2019, 01:35

I learned from Styx, who was super strict on coding format back in the day, and I tend to "correct" other code as I'm fixing bugs or whatever (whether I intend to or not). My bracket style is totally K&R, and I use three spaces for the "indent" when needed. I also have very strong ideas about 40 characters per line and similar stuff thanks to my training from 16ish years ago :P
User avatar
ilmarinen
Posts: 275
Joined: 21 Mar 2019, 22:32

Re: Forming code style standard guidelines

Post by ilmarinen » 24 Jul 2019, 17:56

circe wrote:
24 Jul 2019, 01:35
I learned from Styx, who was super strict on coding format back in the day, and I tend to "correct" other code as I'm fixing bugs or whatever (whether I intend to or not). My bracket style is totally K&R, and I use three spaces for the "indent" when needed. I also have very strong ideas about 40 characters per line and similar stuff thanks to my training from 16ish years ago :P
72 characters per line used to be the standard, as most terminals were only 80 characters wide. Something inherited from F66 age. 40 is some homebrew nonsense.
But that could not have been sg's early standard? "" "" wastes cpu time on concatenation.
I'd strongly advise not to do too many concatinations and use line wrapping feature of your editor insted. It's not only about saving tiny bits of cpu cycles but concerns formatting as well. Especially if it about help files -- line breaks you have for yourself might not correspond with line breaks client has set on their side either via SCREEN env variable or line breaking introduced by their client.
User avatar
circe
Posts: 8
Joined: 09 Jul 2019, 01:22

Re: Forming code style standard guidelines

Post by circe » 29 Jul 2019, 14:16

Will do (or will try to do). I know before we had problems with text blocks that were too long (without concatenation) not showing part of the string, particularly in room descriptions and the like, but also in text/help files.
odin
Posts: 10
Joined: 29 Jul 2019, 14:17

Re: Forming code style standard guidelines

Post by odin » 29 Jul 2019, 14:18

When I rewrite the help statname files to make them 3.5 compatible I didn't use any line breaks... (nevermind, I see that I wasn't supposed to do any concatenations)
garrett
Posts: 7
Joined: 29 Mar 2019, 00:21

Re: Forming code style standard guidelines

Post by garrett » 01 Aug 2019, 20:12

I don't care how you write things, as long as we're not going down the road of the Obfuscated C Contest: https://www.ioccc.org/

The only heinous part of the code that I've written and care to admit was the code that determines how fast weapons decay. I am still so ashamed of that code. :D
odin
Posts: 10
Joined: 29 Jul 2019, 14:17

Re: Forming code style standard guidelines

Post by odin » 01 Aug 2019, 20:12

Then fix it.
User avatar
ilmarinen
Posts: 275
Joined: 21 Mar 2019, 22:32

Re: Forming code style standard guidelines

Post by ilmarinen » 04 Aug 2019, 14:49

Example:

Code: Select all


Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Dolor sed
viverra ipsum nunc aliquet bibendum enim.  In massa tempor nec
feugiat. Nunc aliquet bibendum enim facilisis gravida. Nisl nunc mi
ipsum faucibus vitae aliquet nec ullamcorper. Amet luctus venenatis
lectus magna fringilla.  Volutpat maecenas volutpat blandit aliquam
etiam erat velit scelerisque in. Egestas egestas fringilla phasellus
faucibus scelerisque eleifend.  Sagittis orci a scelerisque purus
semper eget duis.  Nulla pharetra diam sit amet nisl suscipit. Sed
adipiscing diam donec adipiscing tristique risus nec feugiat in. Fusce
ut placerat orci nulla.  Pharetra vel turpis nunc eget lorem
dolor. Tristique senectus et netus et malesuada.

will appear okay on terminals with width of 70+, but on terminals wit width <70 you'll see stuff like:

Code: Select all


Lorem ipsum dolor sit amet, consectetur
adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore
magna aliqua. Dolor sed
viverra ipsum nunc aliquet bibendum enim.
In massa tempor nec
feugiat. Nunc aliquet bibendum enim facilisis
gravida. Nisl nunc mi
ipsum faucibus vitae aliquet nec
ullamcorper. Amet luctus venenatis
lectus magna fringilla.  Volutpat maecenas
volutpat blandit aliquam
etiam erat velit scelerisque in. Egestas egestas
fringilla phasellus
faucibus scelerisque eleifend.  Sagittis orci
a scelerisque purus
semper eget duis.  Nulla pharetra diam sit amet
nisl suscipit. Sed
adipiscing diam donec adipiscing tristique risus
nec feugiat in. Fusce
ut placerat orci nulla.  Pharetra vel turpis
nunc eget lorem
dolor. Tristique senectus et netus et malesuada.

That's just 50 symbols width.

Text typed as

Code: Select all

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Dolor sed viverra ipsum nunc aliquet bibendum enim. In massa tempor nec feugiat. Nunc aliquet bibendum enim facilisis gravida. Nisl nunc mi ipsum faucibus vitae aliquet nec ullamcorper. Amet luctus venenatis lectus magna fringilla. Volutpat maecenas volutpat blandit aliquam etiam erat velit scelerisque in. Egestas egestas fringilla phasellus faucibus scelerisque eleifend. Sagittis orci a scelerisque purus semper eget duis. Nulla pharetra diam sit amet nisl suscipit. Sed adipiscing diam donec adipiscing tristique risus nec feugiat in. Fusce ut placerat orci nulla. Pharetra vel turpis nunc eget lorem dolor. Tristique senectus et netus et malesuada.
Will appear as

Code: Select all

Lorem ipsum dolor sit amet, consectetur
adipiscing elit, sed do eiusmod tempor incididunt
ut labore et dolore magna aliqua. Dolor sed
viverra ipsum nunc aliquet bibendum enim. In
massa tempor nec feugiat. Nunc aliquet bibendum
enim facilisis gravida. Nisl nunc mi ipsum
faucibus vitae aliquet nec ullamcorper. Amet
luctus venenatis lectus magna fringilla. Volutpat
maecenas volutpat blandit aliquam etiam erat
velit scelerisque in. Egestas egestas fringilla
phasellus faucibus scelerisque eleifend. Sagittis
orci a scelerisque purus semper eget duis. Nulla
pharetra diam sit amet nisl suscipit. Sed
adipiscing diam donec adipiscing tristique
risus nec feugiat in. Fusce ut placerat orci
nulla. Pharetra vel turpis nunc eget lorem
dolor. Tristique senectus et netus et malesuada.
But menu linebreaking like (-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-) is the worst, a terminal with the same width would see:

Code: Select all

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-
I keep doing it myself =\ but eventually I'd like to replace it with something else.

The issue expands on any of our ascii art elements, including MOTD. In fact MOTD is the worst: it displays colors BEFORE client identified they support colors. Try to launch your terminal in vt100 mode and look at this:
Image
I'm not sure how urgent is this particular issue issue, but it needs resolving.
User avatar
ilmarinen
Posts: 275
Joined: 21 Mar 2019, 22:32

Re: [NOPE] Forming code style standard guidelines

Post by ilmarinen » 22 Aug 2019, 14:18

Marking it as a nope because we suck.
Post Reply