|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
What is your stance towards using function names/creating new functions to document the function (when you're creating a new method not necessarily used in other places but makes the intent of the code clearer)
def main():
file = getInputFromFile()
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
for j to c:
x[i] = getCharFromFile(file)
doStuff(x)
versus
def doCase(c):
for i to c:
x[i] = getCharFromFile(file)
doStuff(x)
def readCases():
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
doCase(c)
def main():
file = getInputFromFile()
readCases()
Obviously more code but basically that idea. If a group of methods/functions with somewhat complex control flow could be simplified down to a single action, would you prefer wrapping that in a function or prefacing the control flow with a comment.
|
My opinion on that is: whenever you feel the need to put a comment inside a method, you should extract that code into a new method with "the comment as it's name" (you know what I mean).
Sometimes it doesn't work so nicely because the new method would need too many parameters. In that case there's usually still hope that there is a different, better approach to the whole algorithm, which in turn allows for better method extractions.
I really don't care too much about reuse of my methods. I do avoid duplication, of course. If one of my small methods happens to be reusable, great. I also frequently apply a series of inline and extract method refactorings whenever I see some duplicate behavior but my methods aren't quite ready for the situation yet.
|
On October 28 2014 02:52 Blisse wrote:What is your stance towards using function names/creating new functions to document the function (when you're creating a new method not necessarily used in other places but makes the intent of the code clearer)
def main():
file = getInputFromFile()
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
for j to c:
x[i] = getCharFromFile(file)
doStuff(x)
versus
def doCase(c):
for i to c:
x[i] = getCharFromFile(file)
doStuff(x)
def readCases():
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
doCase(c)
def main():
file = getInputFromFile()
readCases()
Obviously more code but basically that idea. If a group of methods/functions with somewhat complex control flow could be simplified down to a single action, would you prefer wrapping that in a function or prefacing the control flow with a comment.
I know that our compiler will inline most functions if it's called under an arbitrary 5 times. So this sort of abstraction has little actual actual effect on code-size. Personal preference then, I guess. There are valid arguments for both styles.
The only correct argument is to be consistent with the practices of nearby code.
On October 28 2014 03:02 spinesheath wrote:
My opinion on that is: whenever you feel the need to put a comment inside a method, you should extract that code into a new method with "the comment as it's name" (you know what I mean).
Sometimes it doesn't work so nicely because the new method would need too many parameters. In that case there's usually still hope that there is a different, better approach to the whole algorithm, which in turn allows for better method extractions.
I really don't care too much about reuse of my methods. I do avoid duplication, of course. If one of my small methods happens to be reusable, great. I also frequently apply a series of inline and extract method refactorings whenever I see some duplicate behavior but my methods aren't quite ready for the situation yet.
+1 for the "comment as it's name".
My personal favorite coding standard is from https://github.com/contiki-os/contiki/blob/master/doc/code-style.c
functions or variables are prepended with the name of the file it comes from, as well, so you can navigate the code-base without a heavy IDE fairly easily.
|
thank you for the advice to a question i posted in page 537.
What im looking for is something graphical and impressive with VERY straight forward to understand code. Ive been programming for the best part of 15 years now and know how long i spent practicing code and exploring and having some of the most accomplished feelings in my life from it. Ive decided to settle down a bit and took a teaching job from games design and stuff like that and feel extremely frustrated with the 11-16yr olds of today. I teach computing of course, our schools most advanced accomplishment is a nested if in excel . . . or a vlookup(rest of staff think they are genius programmers as well when they actually put it up in board and know what the arguments are . . i digress)and even then ive never seen anyone write it out without there being mistakes which ive had to fix in the end anyway.
so ,what am i saying and asking
I tried for years to use flash with them, AS2 was good! AS3 took it all away making it harder to just write scripts into actual objects, now they have to know how to program to an extent and use calls from imports to make anything work the way it did! I personally think its what AS was waiting for, but for the kid . . . nope!
i saw a comp on some site called program a game in a day and some dude made a really good gauntlet/zelda like game using python. I saw the code and thought this isnt so much! kids might get this!
I copied the code, took out everything i didn't need . . infact all i had was a guy running around on some grass and there was a chest you could open. but the [ for x, for y loop into the if x in y ] to draw the tiles threw the kids instantly. they couldnt get their head round a 2d array kind of setup and how the tiles were being drawn to the screen, then came the main entry loop which . . . .well it was over when we got to this bit. Most of the kids had a hard time copying the functions at the start properly.
So, again what am i asking . . not sure but no matter what i try to do, construct of programs seem to get heavy too fast . . .well i say this but i find it insanely straight forward and easy . . .the kids dont get it. All i can do in my lesson in teach them trivial examples, explain whats happening and there we go . . . looks like they are getting it. They cant seem to put this knowledge and practice outside a simple, get a program to output your name, enter a number and display that as your age kind of shit!
Im going to try a class based approach next week and develop something really dumb like a dishwasher . . . god teaching man, kids DONT want to go away and do any extra work or research, if they arent playing COD made by them in 12 minutes its over 
|
"11-16 year olds today" is something countless generations before you have complained about.
Not everyone is talented at or even interested in programming and while I think that most people can learn to program at a moderate level given enough time, I doubt you'll have enough of that. Shouldn't your goal be to teach your students the very basics and then support those who are interested and determined enough to learn more than what can be taught at school?
Just like performance optimization: don't waste development time on random parts of the code. Keep everything reasonable, then profile and focus on the parts that have the most potential for optimization.
|
whats your class, what type of school and is the class mandatory or do they sign up for it?
Important things to know.
mandatory basic excel class in a low education school is different than a course where people can opt out of in a high education school.
In my school we did a program for live predictions for city elections amongst other things, i think a later course did their own browsergame.
But those were optional courses only for people who wanted to learn more about programming, 80% of my school would have been helpless in there, just as i would have been helpless in a painting art class.
|
Has anyone here ever used the pimcore CMS? I've started working for a new company at the end of last week, got assigned some issues pertaining their project using pimcore, which was set up and solely governed by their former employee. No one knows exactly how it works and I've spent past 2 workdays figuring it all out.
Today I've closed 2 issues, which weren't real issues (client got confused) but found some other things that were disturbing:
1. The code that's on the production server doesn't figure on any of the git branches, it's way ahead of master and all the others and there's no way to push it from the production server...
2. While investigating the code and doing some quick fixes for some real issues (had to do it via vim and ssh console) I've discovered that debug.log file has grown to over 200MB over the course of past 2 weeks, most of which were SQL-based errors (majority of them seemed to be state 2002 - unable to open connection to socket), obviously the file was too large for me to parse thoroughly. Investigating php.log revealed some fatal errors involving PDO exceptions... The debug.log is now growing approximately 1MB/hour since people are beginning to fill in content and test it and I have no idea how to handle it in this unfamiliar environment.
Any ideas where to start fixing this? I'm currently looking for a way to disable debug log entirely as the temporary measure, until I figure out what the next course of action should be.
|
|
|
On October 28 2014 06:11 Manit0u wrote:
Has anyone here ever used the pimcore CMS? I've started working for a new company at the end of last week, got assigned some issues pertaining their project using pimcore, which was set up and solely governed by their former employee. No one knows exactly how it works and I've spent past 2 workdays figuring it all out.
Today I've closed 2 issues, which weren't real issues (client got confused) but found some other things that were disturbing:
1. The code that's on the production server doesn't figure on any of the git branches, it's way ahead of master and all the others and there's no way to push it from the production server...
2. While investigating the code and doing some quick fixes for some real issues (had to do it via vim and ssh console) I've discovered that debug.log file has grown to over 200MB over the course of past 2 weeks, most of which were SQL-based errors (majority of them seemed to be state 2002 - unable to open connection to socket), obviously the file was too large for me to parse thoroughly. Investigating php.log revealed some fatal errors involving PDO exceptions... The debug.log is now growing approximately 1MB/hour since people are beginning to fill in content and test it and I have no idea how to handle it in this unfamiliar environment.
Any ideas where to start fixing this? I'm currently looking for a way to disable debug log entirely as the temporary measure, until I figure out what the next course of action should be.
put up a cron job to compress the log (it should compress very nicely) and archive it for later viewing.
Save the most recent few logs from the last week or so into a folder, and remove older logs if the overall folder gets too big. Every week or so, save a log as an archived log to make sure you have snapshots from common errors around that time from production.
Just some ideas. If you don't think the log will be useful at all, you can just remove the file and pipe it straight to /dev/null by putting a link there.
EDIT: And if you're asking how to actually deal with the errors that come up, start with the most egregious sounding error and slowly but surely work your way until the debug log actually has meaning.
EDIT #2: It is probably worth mentioning that the server generating the logs should probably get a good profiling to make sure all that logging isn't slowing down it's response.
|
On October 28 2014 02:52 Blisse wrote:What is your stance towards using function names/creating new functions to document the function (when you're creating a new method not necessarily used in other places but makes the intent of the code clearer)
def main():
file = getInputFromFile()
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
for j to c:
x[i] = getCharFromFile(file)
doStuff(x)
versus
def doCase(c):
for i to c:
x[i] = getCharFromFile(file)
doStuff(x)
def readCases():
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
doCase(c)
def main():
file = getInputFromFile()
readCases()
Obviously more code but basically that idea. If a group of methods/functions with somewhat complex control flow could be simplified down to a single action, would you prefer wrapping that in a function or prefacing the control flow with a comment.
In the second case, the functions should be ordered so they can be read from top to bottom; the first one to be called at the top, and then whichever comes next. In this case: main, followed by readCases, followed by doCase.
|
My fellow nerds! I need your help. I have a C# application due soon and I am stumped. Basically I have to make a simplified version of Paint. What i'm doing for now is drawing Ellipses, Rectangles, and Triangles based on mouse movement. It works pretty nicely, except that when one shape is drawn, the one before that disappears. I know i'm suppose to be using some type of ArrayList to store shapes, but since I have 3 different shapes I am confused as to how to go about that. Here is my code where I add rectangles to the array. (The rectangle is working, but the ellipse and triangles are not being stored)
P.S. Just to not confuse you guys, any code inside the Using(graphics) in my MouseDown event is just to check if a right click falls inside of a created shape. This is in order to open a Properties Dialog that is suppose to be able to change the rotation, location, text, size,width of each drawn shape. I have yet to pass the values, that will be my next monster to tackle.
private void mainFrm_MouseDown(object sender, MouseEventArgs e)
{
initialY = e.Y;
initialX = e.X;
isMoving = true;
using (Graphics g = this.CreateGraphics())
{
if (e.Button == MouseButtons.Right)
{
Point[] ptClick = new Point[] { new Point(e.X, e.Y) };
g.TransformPoints(CoordinateSpace.Page, CoordinateSpace.Device, ptClick);
foreach (Rectangle rect in rectangles)
{
if (rect.Contains(ptClick[0]))
{
options.Show();
}
}
}
}
//this.Invalidate();
}
private void mainFrm_MouseUp(object sender, MouseEventArgs e)
{
isMoving = false;
count++;
//rectangle = new Rectangle(movedX, movedY, width, height);
if (rectangleToolStripMenuItem.Checked == true)
{
rectangles.Add(new Rectangle(movedX, movedY, width, height));
//rectangle = new Rectangle(movedX, movedY, width, height);
}
else if (ellipseToolStripMenuItem.Checked == true)
{
ellipses.Add(new Rectangle(movedX, movedY, width, height));
}
this.Invalidate();
}
private void mainFrm_MouseMove(object sender, MouseEventArgs e)
{
if (isMoving == true)
{
//movedX = e.X - initialX;
//movedY = e.Y - initialY;
triangleX = e.X;
triangleY = e.Y;
movedY = Math.Min(initialY, e.Y);
movedX = Math.Min(initialX, e.X);
width = Math.Max(initialX, e.X) - Math.Min(initialX, e.X);
height = Math.Max(initialY, e.Y) - Math.Min(initialY, e.Y);
rectangles.Insert(0, new Rectangle(movedX, movedY, width, height));
}
this.Invalidate();
}
|
On October 28 2014 02:52 Blisse wrote:What is your stance towards using function names/creating new functions to document the function (when you're creating a new method not necessarily used in other places but makes the intent of the code clearer) + Show Spoiler +
def main():
file = getInputFromFile()
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
for j to c:
x[i] = getCharFromFile(file)
doStuff(x)
versus
def doCase(c):
for i to c:
x[i] = getCharFromFile(file)
doStuff(x)
def readCases():
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
doCase(c)
def main():
file = getInputFromFile()
readCases()
Obviously more code but basically that idea. If a group of methods/functions with somewhat complex control flow could be simplified down to a single action, would you prefer wrapping that in a function or prefacing the control flow with a comment. My advice would be this:
When you split up a function, do it bottom up, not top down. That is, don't cut the function in half, anddef big_f():
f1()
f2() That doesn't really achieve anything. Instead, try to find small small chunks of functionality that can be meaningful on their own, and extract them from the big function. Those will usually take arguments, process them, and return the result, possibly doing a little bit of IO along the way. If you went with the "cut in half" approach, you would have arrived at two weird looking procedures that take nothing, and return nothing.
To elaborate a bit more:
If you refactor# does this and that
def main():
... into# does this
def this():
...
# (possibly hundreds of lines below, or in a different file)
# does that
def that():
...
def main():
this()
that()
Then it becomes easier to see what main() is about, but it comes with a price: that() becomes harder to reason about, as it depends on the state set up by this().
If you instead refactor it like this:def f(a, b):
# (play with a and b to get a result)
return result
def g(a, b):
...
return result
def main():
# (code that uses f() and g())
Then, as long as f() and g() are sensible, everything becomes smaller and easier to grasp.
|
On October 28 2014 09:17 delHospital wrote:Show nested quote +On October 28 2014 02:52 Blisse wrote:What is your stance towards using function names/creating new functions to document the function (when you're creating a new method not necessarily used in other places but makes the intent of the code clearer) + Show Spoiler +
def main():
file = getInputFromFile()
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
for j to c:
x[i] = getCharFromFile(file)
doStuff(x)
versus
def doCase(c):
for i to c:
x[i] = getCharFromFile(file)
doStuff(x)
def readCases():
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
doCase(c)
def main():
file = getInputFromFile()
readCases()
Obviously more code but basically that idea. If a group of methods/functions with somewhat complex control flow could be simplified down to a single action, would you prefer wrapping that in a function or prefacing the control flow with a comment. My advice would be this: When you split up a function, do it bottom up, not top down. That is, don't cut the function in half, and def big_f():
f1()
f2() That doesn't really achieve anything. Instead, try to find small small chunks of functionality that can be meaningful on their own, and extract them from the big function. Those will usually take arguments, process them, and return the result, possibly doing a little bit of IO along the way. If you went with the "cut in half" approach, you would have arrived at two weird looking procedures that take nothing, and return nothing. To elaborate a bit more: If you refactor # does this and that
def main():
... into # does this
def this():
...
# (possibly hundreds of lines below, or in a different file)
# does that
def that():
...
def main():
this()
that() Then it becomes easier to see what main() is about, but it comes with a price: that() becomes harder to reason about, as it depends on the state set up by this(). If you instead refactor it like this: def f(a, b):
# (play with a and b to get a result)
return result
def g(a, b):
...
return result
def main():
# (code that uses f() and g()) Then, as long as f() and g() are sensible, everything becomes smaller and easier to grasp.
I think that's bad. It's way more convenient to have your main function definition at the top and all the helper function definitions below that. The reason is, while inspecting the file you instantly get to the gist of it and if functions have good names you can instantly tell what it does and only have to look up the helper functions if you really need the specifics. Reading random chunks of code doesn't help you understand what the program is actually doing and what its end goal is, you only get that from reading the main function definition. That's why I think it should be the topmost thing.
TL;DR - abstract --> specific is the way to go, not the other way around.
|
On October 28 2014 17:46 Manit0u wrote:Show nested quote +On October 28 2014 09:17 delHospital wrote:On October 28 2014 02:52 Blisse wrote:What is your stance towards using function names/creating new functions to document the function (when you're creating a new method not necessarily used in other places but makes the intent of the code clearer) + Show Spoiler +
def main():
file = getInputFromFile()
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
for j to c:
x[i] = getCharFromFile(file)
doStuff(x)
versus
def doCase(c):
for i to c:
x[i] = getCharFromFile(file)
doStuff(x)
def readCases():
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
doCase(c)
def main():
file = getInputFromFile()
readCases()
Obviously more code but basically that idea. If a group of methods/functions with somewhat complex control flow could be simplified down to a single action, would you prefer wrapping that in a function or prefacing the control flow with a comment. My advice would be this: When you split up a function, do it bottom up, not top down. That is, don't cut the function in half, and def big_f():
f1()
f2() That doesn't really achieve anything. Instead, try to find small small chunks of functionality that can be meaningful on their own, and extract them from the big function. Those will usually take arguments, process them, and return the result, possibly doing a little bit of IO along the way. If you went with the "cut in half" approach, you would have arrived at two weird looking procedures that take nothing, and return nothing. To elaborate a bit more: If you refactor # does this and that
def main():
... into # does this
def this():
...
# (possibly hundreds of lines below, or in a different file)
# does that
def that():
...
def main():
this()
that() Then it becomes easier to see what main() is about, but it comes with a price: that() becomes harder to reason about, as it depends on the state set up by this(). If you instead refactor it like this: def f(a, b):
# (play with a and b to get a result)
return result
def g(a, b):
...
return result
def main():
# (code that uses f() and g()) Then, as long as f() and g() are sensible, everything becomes smaller and easier to grasp. I think that's bad. It's way more convenient to have your main function definition at the top and all the helper function definitions below that. The reason is, while inspecting the file you instantly get to the gist of it and if functions have good names you can instantly tell what it does and only have to look up the helper functions if you really need the specifics. Reading random chunks of code doesn't help you understand what the program is actually doing and what its end goal is, you only get that from reading the main function definition. That's why I think it should be the topmost thing. TL;DR - abstract --> specific is the way to go, not the other way around.
I'm not talking about how functions should be grouped into modules or about the ordering of function definitions in a file. Yes, putting the helper functions below is probably a good idea, but that's not what my post was about. I was saying that you should primarily extract pure-ish, reusable-ish functions that can be reasoned about in isolation, and that simply dividing a procedure into several smaller ones gains you much less.
|
When I want to cut a method into parts, I try to describe what the method does in 2-4 steps and then make those steps my methods. That way I can read the original method as a series of 2-4 steps and then look deeper if I need details about one step. Good steps are usually just those that have a good name and don't require super specific input parameters (so they can work in isolation).
I do think we all mean the same thing here, by the way.
|
On October 28 2014 09:16 Days wrote:+ Show Spoiler +My fellow nerds! I need your help. I have a C# application due soon and I am stumped. Basically I have to make a simplified version of Paint. What i'm doing for now is drawing Ellipses, Rectangles, and Triangles based on mouse movement. It works pretty nicely, except that when one shape is drawn, the one before that disappears. I know i'm suppose to be using some type of ArrayList to store shapes, but since I have 3 different shapes I am confused as to how to go about that. Here is my code where I add rectangles to the array. (The rectangle is working, but the ellipse and triangles are not being stored) P.S. Just to not confuse you guys, any code inside the Using(graphics) in my MouseDown event is just to check if a right click falls inside of a created shape. This is in order to open a Properties Dialog that is suppose to be able to change the rotation, location, text, size,width of each drawn shape. I have yet to pass the values, that will be my next monster to tackle.
private void mainFrm_MouseDown(object sender, MouseEventArgs e)
{
initialY = e.Y;
initialX = e.X;
isMoving = true;
using (Graphics g = this.CreateGraphics())
{
if (e.Button == MouseButtons.Right)
{
Point[] ptClick = new Point[] { new Point(e.X, e.Y) };
g.TransformPoints(CoordinateSpace.Page, CoordinateSpace.Device, ptClick);
foreach (Rectangle rect in rectangles)
{
if (rect.Contains(ptClick[0] )
{
options.Show();
}
}
}
}
//this.Invalidate();
}
private void mainFrm_MouseUp(object sender, MouseEventArgs e)
{
isMoving = false;
count++;
//rectangle = new Rectangle(movedX, movedY, width, height);
if (rectangleToolStripMenuItem.Checked == true)
{
rectangles.Add(new Rectangle(movedX, movedY, width, height));
//rectangle = new Rectangle(movedX, movedY, width, height);
}
else if (ellipseToolStripMenuItem.Checked == true)
{
ellipses.Add(new Rectangle(movedX, movedY, width, height));
}
this.Invalidate();
}
private void mainFrm_MouseMove(object sender, MouseEventArgs e)
{
if (isMoving == true)
{
//movedX = e.X - initialX;
//movedY = e.Y - initialY;
triangleX = e.X;
triangleY = e.Y;
movedY = Math.Min(initialY, e.Y);
movedX = Math.Min(initialX, e.X);
width = Math.Max(initialX, e.X) - Math.Min(initialX, e.X);
height = Math.Max(initialY, e.Y) - Math.Min(initialY, e.Y);
rectangles.Insert(0, new Rectangle(movedX, movedY, width, height));
}
this.Invalidate();
}
I haven't looked at your code but the overall problem you're having could be solved by making a generic 'Shape' class for all your shapes to derive from and then having your container<Shape>. I don't know very much C#, but I take it this shouldn't be too bad?
I hope this helps ^^
|
On October 28 2014 18:27 delHospital wrote:Show nested quote +On October 28 2014 17:46 Manit0u wrote:On October 28 2014 09:17 delHospital wrote:On October 28 2014 02:52 Blisse wrote:What is your stance towards using function names/creating new functions to document the function (when you're creating a new method not necessarily used in other places but makes the intent of the code clearer) + Show Spoiler +
def main():
file = getInputFromFile()
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
for j to c:
x[i] = getCharFromFile(file)
doStuff(x)
versus
def doCase(c):
for i to c:
x[i] = getCharFromFile(file)
doStuff(x)
def readCases():
n = getCharFromFile(file)
for i to n:
c = getCharFromFile(file)
doCase(c)
def main():
file = getInputFromFile()
readCases()
Obviously more code but basically that idea. If a group of methods/functions with somewhat complex control flow could be simplified down to a single action, would you prefer wrapping that in a function or prefacing the control flow with a comment. My advice would be this: When you split up a function, do it bottom up, not top down. That is, don't cut the function in half, and def big_f():
f1()
f2() That doesn't really achieve anything. Instead, try to find small small chunks of functionality that can be meaningful on their own, and extract them from the big function. Those will usually take arguments, process them, and return the result, possibly doing a little bit of IO along the way. If you went with the "cut in half" approach, you would have arrived at two weird looking procedures that take nothing, and return nothing. To elaborate a bit more: If you refactor # does this and that
def main():
... into # does this
def this():
...
# (possibly hundreds of lines below, or in a different file)
# does that
def that():
...
def main():
this()
that() Then it becomes easier to see what main() is about, but it comes with a price: that() becomes harder to reason about, as it depends on the state set up by this(). If you instead refactor it like this: def f(a, b):
# (play with a and b to get a result)
return result
def g(a, b):
...
return result
def main():
# (code that uses f() and g()) Then, as long as f() and g() are sensible, everything becomes smaller and easier to grasp. I think that's bad. It's way more convenient to have your main function definition at the top and all the helper function definitions below that. The reason is, while inspecting the file you instantly get to the gist of it and if functions have good names you can instantly tell what it does and only have to look up the helper functions if you really need the specifics. Reading random chunks of code doesn't help you understand what the program is actually doing and what its end goal is, you only get that from reading the main function definition. That's why I think it should be the topmost thing. TL;DR - abstract --> specific is the way to go, not the other way around. I'm not talking about how functions should be grouped into modules or about the ordering of function definitions in a file. Yes, putting the helper functions below is probably a good idea, but that's not what my post was about. I was saying that you should primarily extract pure-ish, reusable-ish functions that can be reasoned about in isolation, and that simply dividing a procedure into several smaller ones gains you much less.
The rules I go by (mostly C):
1) Functions ought to be ordered in the same order that their prototypes exist in the header file
+ Show Spoiler +The alternative is insanity when trying to navigate between the two
2) global (non-static/exported/public) functions go on the top half, then, a comment line seperates that from static/helper functions that go on the bottom half of a file.
+ Show Spoiler +It should be immediately apparent what the scope of the function you're using is
3) Each file represents precisely one layer of abstraction. No file is too large; no file is too small.
+ Show Spoiler +When working within a file there shouldn't be a requirement to switch to a different file too often. The exception is when you need to know how that module is meant to be used, or you can use a different module.
If your physical layer definitions reach into thousands of lines of code, then you'll find it's easier to have it all in once place rather than having to search two files. If your intermediary glue code only has one or two functions, then the brevity should make it clear where to look for the actual meat, rather than being confused by having that glue code with the code it's glueing.
4) Length of a function doesn't matter so long as it does exactly what the function definition says it does.
+ Show Spoiler +If there is no right place to split up a function into helper functions, it shouldn't be split.
|
On October 28 2014 06:33 Nesserev wrote:Show nested quote +On October 28 2014 06:11 Manit0u wrote:+ Show Spoiler +Has anyone here ever used the pimcore CMS? I've started working for a new company at the end of last week, got assigned some issues pertaining their project using pimcore, which was set up and solely governed by their former employee. No one knows exactly how it works and I've spent past 2 workdays figuring it all out.
Today I've closed 2 issues, which weren't real issues (client got confused) but found some other things that were disturbing:
1. The code that's on the production server doesn't figure on any of the git branches, it's way ahead of master and all the others and there's no way to push it from the production server...
2. While investigating the code and doing some quick fixes for some real issues (had to do it via vim and ssh console) I've discovered that debug.log file has grown to over 200MB over the course of past 2 weeks, most of which were SQL-based errors (majority of them seemed to be state 2002 - unable to open connection to socket), obviously the file was too large for me to parse thoroughly. Investigating php.log revealed some fatal errors involving PDO exceptions... The debug.log is now growing approximately 1MB/hour since people are beginning to fill in content and test it and I have no idea how to handle it in this unfamiliar environment.
Any ideas where to start fixing this? I'm currently looking for a way to disable debug log entirely as the temporary measure, until I figure out what the next course of action should be. Sounds like you're really f*cked... good luck with that.
Took me most of the day, but now there are 3 branches on the git (master, development and production), what is on the deployment server now matches perfectly to what's in the git production branch so you can at least work on it externally and pull to the server. I've also managed to get rid of many unnecessary files and got .htaccess to work (previously it wasn't).
I feel like a young god now.
|
my current metastructure(?) is:
abstraction <-> folder <-> namespace
element <-> file <-> (function or class)
most of the abstractions i work with fit on a workspace or two (1~8 vims).
as long as i can switch to a workspace on one screen
to lookup or twiddle with the relevant code, and as long as i'm
not working with too many simultaneously (1~5 abstractions)
it works.
|
Do you think the future of coding will be 5K to 8K monitors? :3
|
|
|
|
|
|
EPT
