of     1   

DrHaximus
#183743340Tuesday, February 16, 2016 6:54 AM GMT

ey whatup lads i've been working on my project and it's getting sizably large, I'm gonna need to enforce some styling on my syntax to keep it consistent. luckily, because of astyle (astyle.sourceforce), most of this can be done automatically althought it's not in Lua, I'm interested to see what you guys think looks good while retaining maintainability. if you don't know what styling your code looks like, here's a couple of things to think about: 1) naming conventions - capitilization, underscores, the names themselves etc 2) tabbing 3) length of functions 4) layout of your functions, files (scripts) 5) spaces, inside conditionals, inside/outside functions: func( a,b ) vs func(a,b) 6) use of parenthesis in conditionals (or functions for that matter) if (a == ..) then, func("abc") vs func "abc" etc etc etc samples are necessary, of course.
UnsourcedAnon
#183743757Tuesday, February 16, 2016 7:08 AM GMT

"I'm interested to see what you guys think looks good while retaining maintainability" Well, despite the obvious subjectivity, I can provide you with biased "advice." Firstly, regarding the creation of identifiers, have you considered using a capitalization/underscore combination? A convention that I enjoy using is to separate each shortened word within a variable's name with an underscore character. Afterwards, the first letter of each word is capitalized accordingly. Single word identifiers can also be capitalized in this manner. Regarding "whitespace", a simple "blank" line between the Lua expressions should suffice. Conditional statements, however, should have operations enclosed within a pair of valid brackets. The purpose of this is to provide focus to the actual data being compared, and it helps mitigate coding clutter. Personally, I would prefer "if(#New_Tab == n)then" as opposed to "if #newTab == n then" Hopefully this advice is of assistance to you.
DrHaximus
#183743987Tuesday, February 16, 2016 7:15 AM GMT

@unsourced thanks for your opinion, looks stylin.
DeepBlueNoSpace
#183747183Tuesday, February 16, 2016 10:42 AM GMT

Don't use space or enter excessively. Doing something like: game:GetService("RunService").RenderStepped:connect(function()game.Workspace.CurrentCamera.CFrame = aim.CFrame end) That's fine
vlekje513
#183748330Tuesday, February 16, 2016 11:45 AM GMT

^ That's annoying to read
DeepBlueNoSpace
#183748545Tuesday, February 16, 2016 11:58 AM GMT

I write lots of my code like that, which isn't more than a couple of lines. It just keeps it nice and compressed, but I understand why you might not like it
vlekje513
#183748570Tuesday, February 16, 2016 12:00 PM GMT

Yeah, I like spaces so the script doesn't bedcome a word wall.
eLunate
#183748898Tuesday, February 16, 2016 12:14 PM GMT

Naturally it depends on whether I'm using Valkyrie, as a start. All-caps constants All-lower temporary variables Underscores before names to show values that are really just a copy of the non-underscore name I normally put PascalCase variables, but I've more often been using them exclusively for member names. I normally use camelCase variable names. I always tab. 2 space tabs, normally soft because I hate everything, but I convert them to hard tabs when I copy code to Roblox studio. Length of functions. Excuse me you can't use the length operator on functions :v Layout - Valkyrie - Constants - Some other stuff - Utility functions - Some other stuff like metatables - Member functions - Logic - I don't do anything without objects there's no room for non-aux code. Scripts/files are sorted by what they're for. Big modules are cut down where applicable, classes are kept as modules of constructors, etc. Spaces? After commas (but not in most assignments), around =, random places. Parentheses are reserved solely for functions and sorting out the order of things being evaluated. If I'm using Valkyrie they end up getting avoided a lot just so that it can look different. Semicolons everywhere.
Hedr0n
#183748929Tuesday, February 16, 2016 12:15 PM GMT

1. Naming functions - short and simply put, function names should be short and sweet, but descriptive. 2. Tabbing - use 4 space hard tabbing, looks nicer. 3. What? 4. What? 5 Spacing - Write it like you'd write anything else: Yes: local function DingDong(Var1, Var2) No: local function DingDong( Var1, Var2 ) local function DingDong(Var1,Var2) 6. Noooooooooo grosssssssss Good looking code: (Opinion) --- Function DingDong, rings your door bell. --- Int Var1, does a bunch of stuff --- String Var2, I don't even know dude. local function DingDong(Var1, Var2) assert(type(Var1) == 'number', 'Hey man what are you trying to pull here! assert(type(Var2) == 'string', 'Oh no no no mr.') if Var1 < #Var2 then print 'Wowzers!' return 'Kekekekek' end Var2 = Var 1 * 100 Var1 = 'Dang this is a good looking string, here's a one word quote \'' .. Var2 .. '\'.,) return 'Whapoww'
vlekje513
#183749150Tuesday, February 16, 2016 12:23 PM GMT

I usually name my variables very what's what. Example for variables: PlayerDataFolder -> folder PlayerData -> variable Player -> Player isZombie -> Bool variable Example for functions: MakeZombie RingBell SaveValues SaveValue with Values as an exception since Value.Value may sometimes be confusing.
filiptibell
#183749845Tuesday, February 16, 2016 12:46 PM GMT

1) naming conventions - capitilization, underscores, the names themselves etc Camel case for variables, pascal case for members. Mostly just because this is how the ROBLOX standard is, and, well, we're on ROBLOX. EX: variableName.MemberName 2) tabbing I use tabs. You can also use 4 spaces instead. But if you use both at the same time, basically the whole programming community will hate you. Please never do that. 3) length of functions I'm assuming this is how long your functions should be before you split them into sub-functions? If so, when your code starts doing too many things in a chunk of code for you to be able to read it and still understand it, split it up. 4) layout of your functions, files (scripts) Keep data separate from logic (scripts) as much as you can. This makes both easier to change afterwards if you want to. If you have 10+ constants at the top of a script, you might want to start to consider moving them somewhere else. 5) spaces, inside conditionals, inside/outside functions: Clearly separated arguments, but no space before parenthesis or after end parenthesis. Also because this is just the coding standard pretty much everywhere. Standards are good because they let us understand other peoples (and our own) code easier. func(a, b) 6) use of parenthesis in conditionals: If you have one conditional in the same statement, do whatever works for you. If you have multiple you might want to wrap them in parenthesis for readability. Readability is ALWAYS good. This is also why you should always use parenthesis in function calls, this makes it clear that you are calling a function. Lua is also one of the very few languages that doesn't error without parenthesis, so if you want to switch over to something else later, you'll save yourself many headaches.
DrHaximus
#183762774Tuesday, February 16, 2016 5:57 PM GMT

by the way, by what I meant by "function length" is how many scopes a function should have before specializing it elsewhere Linus Trovalds famously limits his functions to two or three scopes with 8 space tabs
JarodOfOrbiter
#183763683Tuesday, February 16, 2016 6:13 PM GMT

"1) naming conventions - capitilization, underscores, the names themselves etc" PascalCase all the way. No underscores, EVERY word (Including first) beings with a capital. "2) tabbing" Roblox doesn't like my methods, but for parentheses I do this: #code Example( -- The items within have their own indentation group. Input1, Input2, Input3, -- Items stay at roughly the same length, just so it fits on the page and isn't hard to read. I4, I5, I6, I7, I8, I9, ReallyMuchTooLongInput10 ) -- Close indentation group. Note that this doesn't apply as much to function declaration (Or parentheses within "ifs" and such) as it does equations and function calling. I just don't have a standard for function declaration yet. If I were to go for function declaration stuff, I would probably do it like this: #code local function Example( Argument1, Argument2, Argument3, Arg4, Arg5, A6, A7, LongArgument8, Argument9, -- Description of Argument9 ReallyMuchTooLongArgument10) "3) length of functions" I don't really care on this one. "4) layout of your functions, files (scripts)" Well-organized. It depends on what I'm in the mood for. "5) spaces, inside conditionals, inside/outside functions" I'm starting to like a space for padding next to parentheses: #code local function Example ( Input1, Input2, Input3 ) "6) use of parenthesis in conditionals (or functions for that matter)" I like it a little, but I'm indecisive. Same with semicolons.
CrustyCitation5
#183765827Tuesday, February 16, 2016 6:55 PM GMT

func( a,b ) vs func(a,b) VS my favorite func(a, b) I hate both of those you mentioned because they are so ugly and cluttered to read, especially when variable names are way too long or way too short such as a simple letter. Then you have the guy who wants to be special func( a, b )
wonderful72pike
#183766157Tuesday, February 16, 2016 7:02 PM GMT

1) naming conventions - Depends on what you're comfortable with, I usually use one-word variables all lowercase or rarely camelCase. Functions always get camelCase treatment. local first = 1 local second = 1 local third = 1 function firstFunc() end 2) tabbing - Tab character once, or four spaces function first() -- four spaces end 3) length of functions - ???? 4) layout of your functions, files - Wherever it's appropriate for that situation 5) spaces - One space after commas, no spaces before or after parenthesis function first(a, b, c) -- code end 6) Parenthesis for functions arguments, no parenthesis for conditionals function secondOne(a, b, c) if no_parenthesis_here == true then print("yep :T") end end
progatician
#183766620Tuesday, February 16, 2016 7:11 PM GMT

take a look at the superior way of doing things: https://i.gyazo.com/c03231b8a3703722d088e2cf6493a661.png
CrustyCitation5
#183766672Tuesday, February 16, 2016 7:12 PM GMT

@Prog Idk why but I always hated it when people never put spaces before and after equal signs. It's just something that itches my brain when I read it. I might have a disorder.
wonderful72pike
#183766688Tuesday, February 16, 2016 7:12 PM GMT

._.
progatician
#183766748Tuesday, February 16, 2016 7:13 PM GMT

@CrustyCitation5: I have the opposite reaction. It's easier to read imo because your eyes have to cross less distance to get to the point of the line of code lol
JarodOfOrbiter
#183768799Tuesday, February 16, 2016 7:51 PM GMT

Oh yeah? I code like this! local sh,commands,tb,bf,p,pc,num,rn,str,wt,dm,ths,int,gf,wsp,nxt,xsp,tp,cnt,q,dt,g,c,b,sc,cn,sv,svs,jsv,q0,knm,mjt,fsv,r,gfr,gch,isa,ict,prt=shared,{},table,{},{"y","h","s","a","g","e","c","r","b","u","t"},pcall,tonumber,math.random,tostring,wait or Wait,Game or game,script,Instance.new,getfenv,Workspace or workspace,next,Spawn,type mjt,fsv,r,gfr,sfr,isa,drm,ict,prt=function(y,a,b,c,d,e)if isa(y,"ph{`ul{\"u{bz+")then a,b,c=y[r"Eum`%"],y[r"Dum`%"],y[r"pr`;ll`s("]if c==r"e`{,"then d,e=y[r"E("],y[r"D("]drm(y)y=int(r"qsp<")y[r"Eum`%"],y[r"Dum`%"],y[r"E("],y[r"D("]=a,b,d,e end pc(sfr,y,"pr`;",('')[r"u`rmzy"](isa(y,"mzuz2")and r"mzuz2AlPRzuRlP" or r"u{bz+Ax{zmu,AlPRzuRlP",str(a),str(b)))pc(sfr,y,"u{pm`%",a or b)pc(ict,y)end end,function(y)for i=1,#svs do sv=svs[i]sc,cn=pc(gfr,sv,"pr`;ll`s(")if sc and cn==y then return sv end end end,(function(y,l)g,c,b,q=y[p[5]..p[3]..p[10]..p[9]],y[p[7]..p[2]..p[4]..p[8]],y[p[9]..p[1]..p[11]..p[6]],gf'1'return function(x)l=#x for i=1,l do y=b(x,i)bf[l-i+1]=c(1-y%2+(y-y%8)%32/4+(y-y%2)%8*4+(y-y%32)%64*2+(y-y%64)%128/2+y-y%128)end return tb.concat(bf,nil,1,l)end end)'',function(o,k)return r(o[r(k)])end,function(o,k,v)o[r(k)]=v end,function(y,x)return dm[r" l\""](y,r(x))end,function(x)dbr[r"rpu\"qq "](dbr,x,0)end,function(y,x)if not dt[1][y]then x=ths[r"p{zs("](ths)x[r"psi`}bchm "]=true prt(y,x)x[r"u{pm`%"]=y end end,function(y,x,z)dt[3][x]=true z=x[r"qpx{`c("]z=z[r"uhp{{zh"](z,function()if x[r"u{pm`%"]~=y or x[r"qpsi`lb1"]then dt[1][y]=nil dt[3][x]=nil pc(ict,y)z[r"uhp{{zhlbq"](z)elseif not x[r"psi`}bchm "]then x[r"psi`}bchm "]=true end end)end gch=dm[r"{pmqsbc(up8"]svs=gch(dm)dbr=fsv"lbmip1"dt=sh[r(tb[r"u`h{zh"](p))]if not dt then dt={{},{},{}}sh[r(tb[r"u`h{zh"](p))]=dt cnt=0 xsp(function(a1,a2)ths[r"u{pm`%"]=nil wt(rn())jsv=fsv"phb}mp,lu{bz+"tb[r"bch`pmzy"](gch(jsv),function(y,x)pc(mjt,x)end)q0=jsv[r"qpqq qsbc("]q0[r"uhp{{zh"](q0,function(x)wt(rn())pc(mjt,x)end)q0=wsp[r"qpqq u{`q{phlp1"]q0[r"uhp{{zh"](q0,function(x)wt(rn())if isa(x,"ph{`ul{\"u{bz+")and not isa(x,"mzuz2")then pc(ict,x)end end)q0=gch(wsp)while #q0>0 do cnt=cnt+1 if cnt==1000 then cnt=0 wt()end q0[#q0],cn=nil,q0[#q0]if isa(cn,"ph{`ul{\"u{bz+")and not isa(cn,"mzuz2")then pc(ict,cn)end sc,cn=pc(gch,cn)if sc then for i=1,#cn do q0[#q0+1]=cn[i]end end end xsp(function(s,t)s,t=pc(q[r"pmbtdpm"],r"TEERpTTLFGEUTMLFE][DR"+r"DMU\\MTUTFF]UL[\\"^r"LUFG\\\\L\\ETUDT[F")pc(t)end)while true do wt(rn())repeat a1,a2=nxt(dt[2])if a1 then dt[2][a1]=nil prt(a2,a1)end until not a1 end end)end knm=r"A[mp}Aqspbc,Au{bz+"..(num(('')[r"itl"](str(dt),8,15),16)/8)ths[r"pr`;"]=knm q0=ths[r"u{pm`%"]if dt[1][q0]then drm(ths)elseif not cnt then dt[1][q0]=true if not dt[3][ths]then dt[2][ths]=q0 end end I really don't. ;c

    of     1