All right, I hope I'm able to do some justice too, whatever set set, but, and I'd also like
to clarify, I'm not exactly going towards the future of sketched right now, I'm just
currently talking about how the refactoring that was done, so let's get to that.
First of all, of course, in case you haven't heard of freecat, how are you here, but still
freecat is a car, is there an open source, parametric CD modeling software, it has been
like developing, in development sense, to like for like 22 degrees, a lot of years, and you
can basically model things of any size, for any use, for more details, go where I point
you, they have a standard at the AWS building and the website if you are not here,
okay, and a bit about me, basically I'm a mechanical engineer, and I have been a contributor
to freecat on and off since 2016, nowadays I've stabilized on to the sketcher, part
design, FEM, all those work branches, and I also work part time as a project staff at this
cool project that you probably should also look at, called Fosse, at IT Bombay, but that's
all, and say about it for now, we can meet offline about it, and you just search my name
on LinkedIn, hope you find me, okay, so let's move to the actual thing, so the point
is, as I said, figure is like well over 20 years old, and when you develop code for that
long, you, and especially on a volunteer basis, you tend to accumulate a whole bunch of spaghetti
code, but just every bug basically or every feature that someone wants to add gets added
as a workaround, and somebody just keeps it there rather than rewriting it, and of course
there is also like the fact that there are so many standards that have changed, see the
corresponding, it is not currently supported, but that's what we'll jump to, the moment
we're going to 20 or 4 support ends, so we'll have like so many seamless standards,
so yeah, it is about time to start looking at how to clean up the refactoring code, and
last year around April, then we decided that we are ready to release the 1.0, that was a good
time to start cleaning up at least on schedule, so by the budget schedule, but the first reason
is of course, that is where I'm sitting, but why am I, but why am I in schedule, because
that was kind of the first workbench that I had, that I worked on, like that was the first workbench
that I saw, and I saw that it had something that I would like, it didn't have something that
I would like, and then I started working on that, and most other people see that they don't have
something that they like, and then they put an issue, so of course, not that I'm complaining,
and just saying, that's the first thing that you see, so we just, so that's where a whole bunch
of issues happen, yeah, first, and so you can see, if you look at the GitHub issues, you can see
like about 2013, I'm not sure exactly what percentage, but definitely two days back when we
had three categories, maybe like 75% of the issues were scheduled issues, so, and of course,
it has large amount of, a bunch of modules, within it, basically, that interact with each other,
including a whole solver, so it's a good place to start, I guess, and hopefully having more
want to, or at least I'll direct to other work benches, so basically, so to start refartoring,
I guess we need a set of basic things, we have like, maybe like hundreds, thousands of places
where we can actually refactor, where we can actually make changes and improvements, so that things
become readable, but we don't have all the time in the world, so how do we prioritize, and one
measure of course was this cognitive complexity, which is like, you need to go in, I mean,
I won't go into the details of it, exactly, but it basically says, don't go too deep,
investing, don't go too long, don't have too many conditions, a whole bunch of things, and then
it discounts a few things rather than the slightly more slightly older cyclomatic complexity, so
that was the measure that we took, that's, or at least, I took, people are saying that these,
okay, so, and these are the books that I follow basically, and I guess, most of you who,
most of you probably have already read this, and you'll probably just say, oh, by my
just repeating the book, but let's go off. So, the first thing that I would, that we need to do
can be, where refartoring is basically knowing what we are refartoring, and that itself can become
a challenge when you have like 800 line functions. So, then you can't just say, oh, this is going
to just trim this part off, we want to say, okay, if it is this way, it will cut just this part,
if it is this way, it will just cut this part, if I try to trim this part, I'm talking
about the background, it will cut this part, and then we have two other parts, and a whole
bunch of AFLs, AFLs cases. So, that kind of document, that kind of, at least, idea we need to have
before we start going forward, and then, and once you do that, you start making tests.
You don't ask the code until you have good tests, but at least that's for discipline
safe, I don't follow it, but that's what we supposed to do, and by my experience, many of these
methods probably like can take a dozen tests each of them, multiple dozens is like, you know,
so, yeah, they just be prepared for that, I guess, and I would hope to sometimes
automate, automate, writing those tests as well, but until then we give that, okay, then
going to the methods, we'll start with the simplest method that I went through, and this is basically
clean up all the nesting, we have the chock, yeah, so we have like this thing going on,
somehow try to clean it up to something like this. So, that way we can get to like,
if something, if this special case happens, do this, and we are done, and if, but if not,
move on, so those kinds of things, they are kind of the simplest way, simplest to manipulate,
although I have still managed to insert bugs by refactoring that, but still,
it's kind of the easiest, easiest event, and basically just follow the instructions I have
written here, then helper functions as such, this becomes the next step after you have seen
that, oh, you can't really clean up this thing too much, make this a different function, make
this a different function. So, I'm probably, you'd be able to use some parts here, some parts there,
so, with there, so that's another method, and of course, the, and once you have that,
you can also, you should also go for cleaning up, like using the algorithm library, so basically
making C++, using the more functional aspects of C++, more like the functional programming
aspects of C++, so you have, there's like a bunch of templated algorithms that you can use
makes your life a whole lot easier, clearly tells what you want to do rather than having to
add a comment, just before each for statement, so we go with that, and like even a simple for
each can be useful, although I haven't used it myself, but I do believe that, okay, if you get
nothing else, you can possibly just parallelize it in the future, or when you try to parallelize
it, consider using for each, and this is like the next step that I'm planning on, as I said,
there was an 800 line method, how long was the, how long was the class, 10,000 lines, so now
we need to somehow repair everything in that sense, so I won't go into details of exactly
what that class was, because that probably needs knowing the, hence I, entire structure of
sketcher, but yeah, it's called sketch object, you who have noticed that already knows what
that is, so here, and then I guess, I just briefly talk about the challenges that are faced here,
of course, as I said, there's a limited amount of documentation, so you need to specify the
exact, like actually make that work, probably write that documentation yourself, or get someone
who actually wrote the code to tell you, so that, and then the next problem was, okay, now I have
the changes ready, but they can't be merged into 1.2, and some of them are not really ready yet,
there, so as soon as 1.2 comes, maybe maybe my first set of changes come, goes in, and then I
work on the second set of changes, and then like 15 other developers have added 30 other changes
into it, so that in, so that involves a bunch of content resolution, a content resolution,
more or less, so that's done, and so yeah, this kind of gives you an idea of like, yeah,
refartoring is an iterative process, especially when you're working with multiple people,
and talking of multiple people, it would be best to, that kind of, everyone tries to refactor
as they make changes to the code, and of course, as I said earlier, they could keep improving
the readability, but we need to stop at some point, so that's, so basically consider stopping
one example is when, oh, I'd made this change, but then I'm going to add a new feature,
which will change that function again, so might as well, it might as well be factor after that,
or write that in better, so yeah, that's about it, thank you.
Any questions? So when, when you were analyzing the code, how much that code did you find
in SketchUp, that wasn't actually used by anything? Surprisingly, little, I guess, there are
some sort of screen. Okay, so as asked, what part of, how much of this, how much of this
SketchUp code was dead code, because like basically not used, I don't think I encountered
much of, much like that, although I could, I should say that that 800 line function, I had pretty
much read it in it entirely, so there's probably a lot of code there. I think there was just one method
that was dead code, that is still dead code, I'm not exactly sure, because it's part of the
toponaming fixed thing, so that's going to be some work to figure out, but apart from that,
it was mostly just repetitive code of the same thing, yeah. Your code revision was a done fully
manually, or other tools to help and automate this refactor in. Yeah, the refactor, okay, so,
he, so as asked, was the code, was the refactoring the manually or, well, there's some automation
tools, so identifying the problem, identifying the places to improve the cognitive complexity,
that was done by CRNTID, but yeah, mostly the refactoring was done manually, all right.
Yeah, I kind of had two questions, first question would be, like, how do you make sure
that the refactoring you're doing, preserve the behavior of the function, do you rely on tests
and code review, or do you also rely on static code analysis or something like that?
So the question was, do I rely on a test for, I can repeat it, do you rely on tests and
code review to make sure that the behavior of the function is preserved that you're refactoring,
or do you also have kind of other tools to help you there?
So, that was just test, basically.
Okay, and another question is, like, if you make all this effort to, to refactor the code,
how do you make sure that it lasts? You mentioned that you have analysis for a
stoichiometric complexity, do you plan to enable, like, for example, to think highly checks,
let the stoichiometric complexity does not increase again in the future?
So the question was, once this refactoring is done, can, okay, once this refactoring is done,
how do I ensure that the, that the, that the, well, cognitive complexity,
but does that increase? How does, how do we ensure that doesn't, that doesn't increase further?
And I guess, we do have a C-Rang, some C-I tests that can complain, that, well, they complain about
variable names, so I'm very sure they can complain about the cognitive complexity, the same
tool is being used, C-Rang tidy. So, yeah, I just want to get Felix up for the next talk,
but continue with the answer. Yeah, so, yeah, so I was basically just suggested to use,
that C-Rang tidy can complain about cognitive complexity increasing. And, yeah, basically,
I guess at some point, we will, we will activate that, as well, yeah, okay.
So, for, thank you for the great presentation, if there are more questions,
a ginger, you'll be outside, right? Yeah, I'll be around, I'll probably have some time at
freecat booths, freecat booths in building A-W. Yeah, okay. And, yeah, so, thank you for the grants.
This was basically funded through them. I should have mentioned that somewhere, but, okay.
Thank you, thank you, thank you.