I’m interested in seeing examples of “bad maxscript code”.
Not code that does malicious things, but rather code that was written that ended up being difficult to maintain, or understand, or was just written poorly. I’m trying to write better code everyday, but often times it helps to see examples of ‘what not to do and why not to do it’.
Here, I’ll start with this beast of a function:
--this function updates the rollout values from parameters
fn syncTheValues objektWidthIN objektWidthRanIN objektWidthRanMinIN objektWidthRanMaxIN objektHeightIN objektHeightRanIN\
objektHeightRanMinIN objektHeightRanMaxIN objektLengthIN objektLengthRanIN objektLengthRanMinIN objektLengthRanMaxIN\
hasTopFaceIN hasBotFaceIN hasWidthELIN elwAmountIN elwranIN elwRanMinIN elwRanMaxIN elwSegsIN hasHeightELIN\
elhAmountIN elhranIN elhRanMinIN elhRanMaxIN elhSegsIN hasLengthELIN ellAmountIN ellranIN ellRanMinIN ellRanMaxIN ellSegsIN\
tsmoothOneAmountIN hasShellIN shellAmountIN shellAmountRanIN shellAmountRanMinIN shellAmountRanMaxIN shellSegsIN shellInoutIN\
FFDtopInsetAmountIN FFDmidInsetAmountIN FFDbotInsetAmountIN tsmoothTwoAmountIN tsmoothTwoRenAmountIN = ( --open fn
objektWidth=objektWidthIN;objektWidthRan=objektWidthRanIN;objektWidthRanMin=objektWidthRanMinIN
objektWidthRanMax=objektWidthRanMaxIN;objektHeight=objektHeightIN;objektHeightRan=objektHeightRanIN
objektHeightRanMin=objektHeightRanMinIN;objektHeightRanMax=objektHeightRanMaxIN;objektLength=objektLengthIN
objektLengthRan=objektLengthRanIN;objektLengthRanMin=objektLengthRanMinIN;objektLengthRanMax=objektLengthRanMaxIN
hasTopFace=hasTopFaceIN;hasBotFace=hasBotFaceIN;hasWidthEL=hasWidthELIN;elwAmount=elwAmountIN;elwran=elwranIN;elwRanMin=elwRanMinIN
elwRanMax=elwRanMaxIN;elwSegs=elwSegsIN;hasHeightEL=hasHeightELIN;elhAmount=elhAmountIN;elhran=elhranIN;elhRanMin=elhRanMinIN
elhRanMax=elhRanMaxIN;elhSegs=elhSegsIN;hasLengthEL=hasLengthELIN;ellAmount=ellAmountIN;ellran=ellranIN;ellRanMin=ellRanMinIN
ellRanMax=ellRanMaxIN;ellSegs=ellSegsIN;;tsmoothOneAmount=tsmoothOneAmountIN;hasShell=hasShellIN;shellAmount=shellAmountIN
shellAmountRan=shellAmountRanIN;shellAmountRanMin=shellAmountRanMinIN;shellAmountRanMax=shellAmountRanMaxIN;shellSegs=shellSegsIN
shellInout=shellInoutIN;FFDtopInsetAmount=FFDtopInsetAmountIN;FFDmidInsetAmount=FFDmidInsetAmountIN;FFDbotInsetAmount=FFDbotInsetAmountIN
tsmoothTwoAmount=tsmoothTwoAmountIN;tsmoothTwoRenAmount=tsmoothTwoRenAmountIN
) --close fn
All this function does is update values. That’s it. And it’s incredibly dense text, which makes it difficult to maintain or modify later on. This is from an older script I wrote, and when I looked at this fn recently, I cringed. Never write a function like this unless you plan on hating yourself later. It accepts too many parameters (I think the recommended is less than 8), and doesn’t return any kind of success or failure, so you don’t know if it worked or not.
I know a lot of people don’t like to talk about their bad code. In fact, some folks encrypt their code because they don’t want other people seeing their ‘bad’ code. But I say, let the warts show. I’m not ashamed that I don’t know everything, and I feel humbled everyday when reading other’s code. So, lets learn from each others mistakes!
This thread is partially inspired by this thread on stackoverflow.
And this thread as well. < it’ll make you laugh
To make it easier use white space, put everything on new lines instead of using “;” and continuing. Use comments in your code to help define what does what so it is easy to find where things happen.
Much of the “bad” code that I see isn’t code that doesn’t work but code that can’t be read and updated. I have seen coders, especially in MEL, code everything left justified, no spacing and just plane messy.
I prefer the other method of “()” where each is on a new line and that is the only thing on that line. I find that it makes it easier to see where code starts and ends as it is well defined. Trying to save a line here and there just makes it harder to read and doesn’t make it faster or less error prone.
Good input PEN!
Here’s some (paraphrased) code that I ran across in another one of my scripts:
(
fn fnThree = (does some stuff)
fn fnTwo = (does some stuff; fnThree)
fn fnOne = (does some stuff; fnTwo)
)
vs.
fn justOne = (does some stuff)
In this code, I didn’t have a reason to forward declare a function, and then have a function call that function later on. I had no reason to nest the functions the way I did, and it only added to the complexity of the code. Why use “more” when you can get by with “just one”? If those functions were more general in nature, then there would be a reason to have them as their own functions. And, you could always turn these functions into methods of a struct.
Anybody have any object oriented code nightmares (architecture astronauts?)