C.S. class WTF
-
@blakeyrat said:
What about conditional breakpoints? I'd say it looks ... barely acceptable.
You are aware that gdb does them? Has done for years. (Never used them personally due to the kinds of programs I write, but they're well documented.)
@Mason Wheeler said:
What's with the hots for the event log? Is logging directly to an ordinary file so hard on Windows? (This was always something I didn't understand properly; must be some fundamental difference which just escapes me.) Unix programmers would not write to the system log when debugging; they'd use a private log instead, and that doesn't need any kind of fancy technology to work reliably.- Evaluate an expression and log the result to the event log
- Log the call stack
- Turn on or off other breakpoints labeled with an arbitrary "group name"
- Log an arbitrary message to the event log
But that quibbling aside, the functionality you describe can be done inside gdb (the labelling corresponds to storing the breakpoint IDs in a debugger variable — effectively an arbitrary label — which can then be toggled as a group at any point, including conditionally on some other breakpoint). So far as I can see, the main thing that commercial IDEs offer over gdb on the debugging front is a fancier interface. Which is fair enough, actually; a good user interface adds plenty of value even if it is using fundamental functionality that already exists in the underlying system.
-
@dkf said:
Unix programmers would not write to the system log when debugging; they'd use a private log instead, and that doesn't need any kind of fancy technology to work reliably.
Rubbish.
[root@xxx ~]# cat /etc/syslog.conf
# Begin /etc/syslog.conf
auth,authpriv. @xxx_global_ip:515
auth,authpriv. -/var/log/auth.log
.;.!=debug;auth,authpriv.none -/var/log/sys.log
daemon.;daemon.!=debug -/var/log/daemon.log
kern.;kern.!=debug -/var/log/kern.log
mail.;mail.!=debug -/var/log/mail.log
user.;user.!=debug -/var/log/user.log
cron.;cron.!=debug -/var/log/cron.log
.info;mail.none;authpriv.none;cron.none -/var/log/messages
.emerg
# log the bootscript output:
local2. -/var/log/boot.log
# Log debug to a separate file
#*.debug -/var/log/debug.log
# End /etc/syslog.conf
[root@xxx ~]#
-
@dkf said:
@blakeyrat said:
What about conditional breakpoints? I'd say it looks ... barely acceptable.
You are aware that gdb does them? Has done for years. (Never used them personally due to the kinds of programs I write, but they're well documented.) @Mason Wheeler said:
What's with the hots for the event log? Is logging directly to an ordinary file so hard on Windows? (This was always something I didn't understand properly; must be some fundamental difference which just escapes me.) Unix programmers would not write to the system log when debugging; they'd use a private log instead, and that doesn't need any kind of fancy technology to work reliably.- Evaluate an expression and log the result to the event log
- Log the call stack
- Turn on or off other breakpoints labeled with an arbitrary "group name"
- Log an arbitrary message to the event log
Sorry; terminology confusion. I'm not talking about the system event log; I'm talking about the debugger event log, which is kept in its own window in the IDE. It does not get dumped to a file (which is good because 99% of the time you don't need it to be persisted, and so you don't end up with tons of log data filling up your hard drive) and if you need it you can copy the text out and into Notepad or tell the IDE to save it to a file. It gets cleared every time you start the debugger, which means it will stick around after the end of your last debugging session until the point when you begin the next one.
It's a lot more convenient than "logging directly to an ordinary file" when you think about it. (Which is kind of the point. They actually thought about it when they designed it; they put a lot of thought and effort into usability, instead of just following the lazy Unix philosophy of "let's make everything a text file because we should make everything a text file.")
-
@PJH said:
Rubbish.
No. I've never seen anyone log to syslog from a debugger, nor can I find anyone writing about doing it online with a quick search. (That's different to merely writing to syslog at the debug detail level.) When people use logging from debuggers on Unix, they log to a normal file.
-
@Mason Wheeler said:
Sorry; terminology confusion. I'm not talking about the system event log; I'm talking about the debugger event log, which is kept in its own window in the IDE. It does not get dumped to a file (which is good because 99% of the time you don't need it to be persisted, and so you don't end up with tons of log data filling up your hard drive) and if you need it you can copy the text out and into Notepad or tell the IDE to save it to a file. It gets cleared every time you start the debugger, which means it will stick around after the end of your last debugging session until the point when you begin the next one.
Oh, you mean like logging to a named pipe?
-
@dkf said:
from a debugger
Ah - I misunderstood. Thought this was syslog() from the program itself...
-
@dkf said:
Oh, you mean like logging to a named pipe?
I've known a lot of stoners that named their pipes. But they usually talked about trees, and not logs...
Seriously though, have you ever tried to explain a named pipe to a M$ guy without being able to demonstrate it? I've known people that simply directed the output to another tty as well.
-
@dkf said:
You are aware that gdb does them?
Yes, I only ask questions I already know the answer to.
@dkf said:
What's with the hots for the event log?
- It enforces a standard format
2) It guarantees basic information is present, even if the programmer is an idiot (process name, date/time, etc)
3) You can automate culling of old records so the programmer doesn't have to worry about filling up the disk with logs
4) Provides the log to the network, so that it can be read from another computer or, alternatively, events can be logged to another computer in the first place
Basically it does a lot of the boring stuff for you automatically, so the programmer doesn't have to worry about it. If you've ever seen a computer come crashing to a halt because some runaway process filled up the disk with its log file, you should immediately understand the need.
@dkf said:
Unix programmers would not write to the system log when debugging; they'd use a private log instead, and that doesn't need any kind of fancy technology to work reliably.
Yes it does. I just gave an example. Unless you're going to tell me that obviously even Unix programmer was God's Gift To Programming and wrote perfect code and would never, EVER, EVER, even for debugging, write a log file function that would fill up the disk and bring the computer to a halt because Unix programmers are holy, perfect beings not capable of error! In which case you'd be a lying liar.
EDIT: Above confusion about the term "event log" applies to this post as well, because I didn't read all the posts before replying because I am a jerk who is dumb
- It enforces a standard format
-
@DrakeSmith said:
Seriously though, have you ever tried to explain a named pipe to a M$ guy without being able to demonstrate it?
Aw fuck, Slashdot's leaking again.
-
@DrakeSmith said:
Seriously though, have you ever tried to explain a named pipe to a M$ guy without being able to demonstrate it?
I have never heard the phrase "named pipe" before (within the context of computing) but DOS had the ability to pipe or redirect output (usually to a file, but you could also pipe normally-hidden debug output to the console), so isn't the term somewhat self-explanatory? It's a pipe that has a name, which I assume means that you can open it and read the output contained in its buffer, perhaps even in real-time as if it were a virtual TTY or LPT port. Or am I just the only M$ guy who knows what a pipe is or has any imagination on how you might use one for debugging?
-
-
@Mason Wheeler said:
What's so weird about that? "g++ <main_file.cpp>" should take care of all your college-level compiling needs.
And "g++ *.cpp" takes care of your multi-source-file needs.
@Mason Wheeler said:
As I mentioned earlier, I did everything from Visual Studio, back at my dorm. I would then Telnet in to the lab, copy/paste the completed work into VI
Why would you do that when you should be able to just FTP the file?
-
@FrostCat said:
@Mason Wheeler said:
What's so weird about that? "g++ <main_file.cpp>" should take care of all your college-level compiling needs.
And "g++ *.cpp" takes care of your multi-source-file needs.
@Mason Wheeler said:
As I mentioned earlier, I did everything from Visual Studio, back at my dorm. I would then Telnet in to the lab, copy/paste the completed work into VI
Why would you do that when you should be able to just FTP the file?
...to compile, run and test it under g++, as I explained. Just in case there are cross-platform differences at work.
-
@anotherusername said:
@DrakeSmith said:
Seriously though, have you ever tried to explain a named pipe to a M$ guy without being able to demonstrate it?
I have never heard the phrase "named pipe" before (within the context of computing) but DOS had the ability to pipe or redirect output (usually to a file, but you could also pipe normally-hidden debug output to the console), so isn't the term somewhat self-explanatory? It's a pipe that has a name, which I assume means that you can open it and read the output contained in its buffer, perhaps even in real-time as if it were a virtual TTY or LPT port. Or am I just the only M$ guy who knows what a pipe is or has any imagination on how you might use one for debugging?It's actually not something you can do in DOS, because it's not about "piping" DOS style; it's about concurrent IPC.
It's a global OS object referred to by a name. Your program opens a pipe by name [for reading/for writing] and another program opens a pipe by the same name for the opposite operation, and they're able to pass data through it, basically as what we'd call a stream today.
And I don't see why MS guys wouldn't understand it; Windows supports them as a standard OS feature. Maybe it's just because the main Windows feature for program communication in general--the Windows message system--works just as well between programs as within your own program.
-
@beginner_ said:
Well a standard format is acceptable but the according software should be easily and freely available to student.
[url=http://www.microsoft.com/en-us/download/details.aspx?id=34673]HTH, HAND.[/url](Assumes that "walk into the lab and sit down in front of an unoccupied computer" isn't "freely available" enough.
-
@Sir Twist said:
I believe you meant this.@beginner_ said:
Well a standard format is acceptable but the according software should be easily and freely available to student.
HTH, HAND.(Assumes that "walk into the lab and sit down in front of an unoccupied computer" isn't "freely available" enough.
-
@Mason Wheeler said:
It's actually not something you can do in DOS, because it's not about "piping" DOS style; it's about concurrent IPC.
It's a global OS object referred to by a name. Your program opens a pipe by name [for reading/for writing] and another program opens a pipe by the same name for the opposite operation, and they're able to pass data through it, basically as what we'd call a stream today.
That's basically what I said. DOS did have pipes and I/O redirection, although they were originally pretty basic - more functionality was added with DOS under Windows NT. The main difference is that you can't name a pipe and have another application open it by name.
http://www.robvanderwoude.com/redirection.php has some examples of I/O redirection in DOS. You can do a lot more than just COMMAND1 | COMMAND2 or COMMAND1 > file.
-
@anotherusername said:
@Mason Wheeler said:
It's actually not something you can do in DOS, because it's not about "piping" DOS style; it's about concurrent IPC.
It's a global OS object referred to by a name. Your program opens a pipe by name [for reading/for writing] and another program opens a pipe by the same name for the opposite operation, and they're able to pass data through it, basically as what we'd call a stream today.
That's basically what I said. DOS did have pipes and I/O redirection, although they were originally pretty basic - more functionality was added with DOS under Windows NT. The main difference is that you can't name a pipe and have another application open it by name.
has some examples of I/O redirection in DOS. You can do a lot more than just COMMAND1 | COMMAND2 or COMMAND1 > file.No, what DOS calls "pipes" have nothing to do with named pipes. DOS "pipes" are about sequential I/O redirection. Named pipes are about communication between concurrent processes, which DOS had no support for because it didn't support concurrent processes in the first place.
And lest you think that this is just a pedantic difference in semantics, it's possible to create two named pipes, A and B, and process 1 opens A for reading and B for writing, and process 2 opens B for reading and A for writing, and then they can communicate back and forth to each other. You can't do that with sequential piping.
-
@Mason Wheeler said:
No, what DOS calls "pipes" have nothing to do with named pipes. DOS "pipes" are about sequential I/O redirection. Named pipes are about communication between concurrent processes, which DOS had no support for because it didn't support concurrent processes in the first place.
And lest you think that this is just a pedantic difference in semantics, it's possible to create two named pipes, A and B, and process 1 opens A for reading and B for writing, and process 2 opens B for reading and A for writing, and then they can communicate back and forth to each other. You can't do that with sequential piping.
Yeah, but it's the same basic fucking idea. If you understand MSDOS pipes it's not a huge jump to named pipes, conceptually.
-
@Clueless_Luser said:
To those who have stated this isn't a WTF, I must respectfully disagree, and here's why:
- I'm well aware that day jobs will frequently mandate painful, obtuse and/or suboptimal development environments (in fact, I've worked at places that did this). However, in this case, I'm not a paid employee, but rather a paying customer, and as such, I feel I should be able to request platform-agnosticism and get it.
Ah yes, the entitlement mentality. This idea of education as a consumer product is not that new. I saw it when teaching for the University of Phoenix lo these many years ago. Lemme tell you something: you're not a special snowflake. You're a student in an introductory class. You don't get to dictate how you are being instructed, or the tools you must use to complete that instruction. Other posters are correct in their statements to you that this is the way the world works. If you don't like the requirements for the class, drop it. Better yet, do some more research into other CS programs and transfer to one that is more your liking.
[/Troll]
-
@slavdude said:
Ah yes, the entitlement mentality. This idea of education as a consumer product is not that new. I saw it when teaching for the University of Phoenix lo these many years ago. Lemme tell you something: you're not a special snowflake. You're a student in an introductory class. You don't get to dictate how you are being instructed, or the tools you must use to complete that instruction. Other posters are correct in their statements to you that this is the way the world works. If you don't like the requirements for the class, drop it. Better yet, do some more research into other CS programs and transfer to one that is more your liking.
[/Troll]
You're trolling, but you actually raise a good point. If OP really knows the best way to teach him, he could just teach himself for free and not bother with college. So the OP is either off base for the reasons that you mention, or an idiot for bothering with college.
-
@PedanticCurmudgeon said:
So the OP is either off base for the reasons that you mention, or an idiot for bothering with college
So... he is an idiot either way
-
-
@boomzilla said:
@serguey123 said:
Finally, something we can agree onSo... he is an idiot either way
Aren't we all?
-
@boomzilla said:
Yeah, but it's the same basic fucking idea. If you understand MSDOS pipes it's not a huge jump to named pipes, conceptually.
Originally, DOS didn't have pipes. It simulated them with files. (Ick!) Things have been better than that for a long time, thank goodness. These days, true pipes are there in Windows as they are on more strongly POSIX-y OSes, and so are named pipes. (There are definite advantages to putting IPC primitives in the filesystem as special device endpoints; in particular, they mean you don't have to invent a whole separate discovery and management API.)There are differences between platforms in other IPC mechanisms. Windows has got some pretty reasonable message primitives, and Unix has sockets (both stream-based and datagram-based) in the filesystem; I think neither has a precise equivalent in the other…
-
@blakeyrat said:
@dkf said:
You are aware that gdb does them?
Yes, I only ask questions I already know the answer to.
Boring! I like asking questions which I don't know the answer for, so I can at least go to knowing what other people think the answer is.
@blakeyrat said:@dkf said:
Much like syslog then. Cool. @blakeyrat said:What's with the hots for the event log?
- It enforces a standard format
2) It guarantees basic information is present, even if the programmer is an idiot (process name, date/time, etc)
3) You can automate culling of old records so the programmer doesn't have to worry about filling up the disk with logs
4) Provides the log to the network, so that it can be read from another computer or, alternatively, events can be logged to another computer in the first place
Basically it does a lot of the boring stuff for you automatically, so the programmer doesn't have to worry about it. If you've ever seen a computer come crashing to a halt because some runaway process filled up the disk with its log file, you should immediately understand the need.
@dkf said:
Meh. While I wouldn't want to claim most programmers were great or anything like that, filling up the disk with logs tends to not happen much when you've got a debugger attached. (Now, overnight when you've left the debug level logging switched on in a heavily exposed web service… but that's a different scenario only related by the words “debug” and “log” and no actual facts. Oh well, at least it absolutely guaranteed that nobody was going to break into that service. It was long ago…) In any case, the key observation is that when it comes to debug logs, disk is usually not an issue. In fact, where a log is big enough to matter, you probably have to be careful anyway; losing bits off the front to log rotation is likely to cause important info to be lost and you won't be able to hold it just in memory (with any vaguely normal hardware config; most people have more spare disk than total RAM).Unix programmers would not write to the system log when debugging; they'd use a private log instead, and that doesn't need any kind of fancy technology to work reliably.
Yes it does. I just gave an example. Unless you're going to tell me that obviously even Unix programmer was God's Gift To Programming and wrote perfect code and would never, EVER, EVER, even for debugging, write a log file function that would fill up the disk and bring the computer to a halt because Unix programmers are holy, perfect beings not capable of error! In which case you'd be a lying liar.To summarise this whole subthread: the main thing IDEs bring to debugging is a graphical interface and integration with non-debugging bits of the IDE. You can hide a lot behind a clever GUI.
- It enforces a standard format
-
@dkf said:
@blakeyrat said:
@dkf said:
You are aware that gdb does them?
Yes, I only ask questions I already know the answer to.
Boring! I like asking questions which I don't know the answer for, so I can at least go to knowing what other people think the answer is.I think your sarcasm detector may need recalibrating
-
@RTapeLoadingError said:
@dkf said:
@blakeyrat said:
@dkf said:
You are aware that gdb does them?
Yes, I only ask questions I already know the answer to.
Boring! I like asking questions which I don't know the answer for, so I can at least go to knowing what other people think the answer is.I think my sarcasm detector may need recalibrating
FTFY
-
-
@Snooder said:
I really don't see the big problem here. The problem isn't really that the grader can't get your shit working in whatever random form you send it in. It's that in a class of 100+ people, having to have him dick around for an hour reformatting and recompiling shit for every single person who decides to follow their own individual and indeosyncratic format is a massive waste of time. That he prefers to run VS2012 in Windows 7 is just as valid as you prefering to run gcc in Ubuntu. And since he's the one handing out grades, you'd better make his job easier so he's in a better mood.
How about requiring the sourcecode to be in a single file instead of dicking around with retarded VS projects or makefiles in the first place?
-
@Faxmachinen said:
How about requiring the sourcecode to be in a single file instead of dicking around with retarded VS projects or makefiles in the first place?
Let's go straight for the jugular. Source code must be on a single line. No problems with platform line separator differences any more!!!
-
@dkf said:
Let's go straight for the jugular. Source code must be on a single line. No problems with platform line separator differences any more!!!
I was being serious though. Most decent languages (i.e. not Java) let you have a good structure regardlessly.
-
@Clueless_Luser said:
I asked for Clueless_Luser's line of thinking.
Ben L. put this about as well as I could have.To add another layer of WTFishness, we have an assignment that needs to draw something, but we're explicitly banned from using any cross-platform libraries to do so.
The best thing I got out of my education was flexibility. When you get hired into a job, in all likelihood anyway, you get a computer with a given OS, a given development environment, etc. You don't get to choose which, at least in the majority of cases. You're expected to be a well rounded and adjustable employee who can use the tools given to accomplish his task, and if you can't do that, you won't be employed long.
-
@Master Chief said:
The best thing I got out of my education was flexibility.
My best thing was exposure to lots of different things.
That may or may not run counter to your point.
-
@Faxmachinen said:
@dkf said:
Let's go straight for the jugular. Source code must be on a single line. No problems with platform line separator differences any more!!!
I was being serious though. Most decent languages (i.e. not Java) let you have a good structure regardlessly.
You're kidding right? Having all source code inside a single file isn't bad for language reasons, it's bad because it's a bad way to design code and creates a massive unreadable mess. It's the equivalent of writing a 100 page book with only one chapter. BTW, Java lets you put your source code within a single file just like any other language. I think what you mean is that Java should compile into executable files natively. But that defeats the main purpose of writing java in the first place, OS independence.
-
@Snooder said:
You're kidding right? Having all source code inside a single file isn't bad for language reasons, it's bad because it's a bad way to design code and creates a massive unreadable mess. It's the equivalent of writing a 100 page book with only one chapter.
No, putting your entire source code into a single massive function called main() is the equivalent of a 100 page book with only one chapter. Modular programming uses functions. There is no sane reason why every function in a project necessarily needs to be a separate source code file. Your IDE should make it seamless anyway; it won't matter whether the function is in the same source file or a different one. If you need to jump to that function, it'll just put you there regardless of where it's actually located.
-
@anotherusername said:
@Snooder said:
You're kidding right? Having all source code inside a single file isn't bad for language reasons, it's bad because it's a bad way to design code and creates a massive unreadable mess. It's the equivalent of writing a 100 page book with only one chapter.
No, putting your entire source code into a single massive function called main() is the equivalent of a 100 page book with only one chapter. Modular programming uses functions. There is no sane reason why every function in a project necessarily needs to be a separate source code file. Your IDE should make it seamless anyway; it won't matter whether the function is in the same source file or a different one. If you need to jump to that function, it'll just put you there regardless of where it's actually located.
I have to maintain a site that uses this technique. The vast majority of the code lives in a single file, which is essentially called mySite.cs, and clocks in at 8517 lines. While this is far from the most frustrating thing about this site, it sucks and I hate it.
-
@mikeTheLiar said:
@anotherusername said:
No, putting your entire source code into a single massive function called main() is the equivalent of a 100 page book with only one chapter. Modular programming uses functions. There is no sane reason why every function in a project necessarily needs to be a separate source code file. Your IDE should make it seamless anyway; it won't matter whether the function is in the same source file or a different one. If you need to jump to that function, it'll just put you there regardless of where it's actually located.
I have to maintain a site that uses this technique. The vast majority of the code lives in a single file, which is essentially called mySite.cs, and clocks in at 8517 lines. While this is far from the most frustrating thing about this site, it sucks and I hate it.I will concede that if a CS coding project takes anywhere near 8500 lines of code, then it would probably make sense to break it into more than one file. However, most CS projects aren't anywhere near that large, and will be perfectly manageable as a single source code file.
For a large project, such as a real-world application, yes: it does make sense to make some logical divisions in the source code and break it apart into multiple files. However, I still don't see any great need to have exactly one function per source file.
-
@anotherusername said:
However, I still don't see any great need to have exactly one function per source file.
This was a very clever straw man, BTW. Well done on that.
-
@boomzilla said:
@anotherusername said:
However, I still don't see any great need to have exactly one function per source file.
This was a very clever straw man, BTW. Well done on that.
I hope he meant one object. I can get behind one object (not including nested objects, obviously) per file.
-
@anotherusername said:
if a CS coding project takes anywhere near 8500 lines of code
It shouldn't. The original developer was an idiot.
-
@boomzilla said:
@anotherusername said:
However, I still don't see any great need to have exactly one function per source file.
This was a very clever straw man, BTW. Well done on that.
I left that caveat intentionally because I knew that even though we're talking about small programming projects for someone's CS classes, someone was bound to come along and say that they had an umpteen thousand line bear of a source file that was known to eat small children (and the occasional intern). That's why I originally said, "There is no sane reason why every function in a project necessarily needs to be a separate source code file," instead of, "there's no sane reason why any project ever needs to have more than one source file".
There are reasons why a project would need to have more than one source file. There aren't very many reasons why a CS project ever would; an application that large takes longer than a few days or weeks to develop.
-
@mikeTheLiar said:
I hope he meant one object. I can get behind one object (not including nested objects, obviously) per file.
Sure, I'll concede that most of the time an object should be defined in its own source file, even in a small project.
-
@anotherusername said:
@boomzilla said:
@anotherusername said:
However, I still don't see any great need to have exactly one function per source file.
This was a very clever straw man, BTW. Well done on that.
I left that caveat intentionally because I knew that even though we're talking about small programming projects for someone's CS classes, someone was bound to come along and say that they had an umpteen thousand line bear of a source file that was known to eat small children (and the occasional intern). That's why I originally said, "There is no sane reason why every function in a project necessarily needs to be a separate source code file," instead of, "there's no sane reason why any project ever needs to have more than one source file".Is English not your native language? Why "one function per source file?" Has anyone, ever, advocated this (aside from the everything in one function sort of people? Because the way you said it, it sounds like there would be more than one.
-
@boomzilla said:
Why "one function per source file?" Has anyone, ever, advocated this (aside from the everything in one function sort of people?
Why, indeed. If your project only has a few functions, it's simplest to just put them all in one file. Classes or objects can be contained in separate files, but even that's only necessary if you mean them to be portable.
-
@anotherusername said:
@boomzilla said:
Why "one function per source file?" Has anyone, ever, advocated this (aside from the everything in one function sort of people?
Why, indeed. If your project only has a few functions, it's simplest to just put them all in one file. Classes or objects can be contained in separate files, but even that's only necessary if you mean them to be portable.OK, no interesting story, just random trolling. Thanks.
-
@mikeTheLiar said:
I can get behind one object
I used to go behind one object all the time. Especially when that object was the sofa and Dr. Who was on. (Some of the monsters were really frightening at that time, but that was long ago.)
-
@anotherusername said:
@Snooder said:
You're kidding right? Having all source code inside a single file isn't bad for language reasons, it's bad because it's a bad way to design code and creates a massive unreadable mess. It's the equivalent of writing a 100 page book with only one chapter.
No, putting your entire source code into a single massive function called main() is the equivalent of a 100 page book with only one chapter. Modular programming uses functions. There is no sane reason why every function in a project necessarily needs to be a separate source code file. Your IDE should make it seamless anyway; it won't matter whether the function is in the same source file or a different one. If you need to jump to that function, it'll just put you there regardless of where it's actually located.
No, putting all code into a single massive function is like having a 100page book with only one paragraph. It's not just unreadable, but actually grammatically/syntactically wrong. I used the analogy of chapters to illustrate the point that it's not necessary for the code to work, but is a good way to organize logically related thoughts to make it easier for humans to read and understand. Just your choice of what functions to place together alone tells a later reader (which might be yourself) a lot about your thought process and thus helps them understand what the code was supposed to do.
-
@Snooder said:
No, putting all code into a single massive function is like having a 100page book with only one paragraph. It's not just unreadable, but actually grammatically/syntactically wrong.
But possibly a modernist masterpiece. That's literature for you.
-
@anotherusername said:
There are reasons why a project would need to have more than one source file. There aren't very many reasons why a CS project ever would; an application that large takes longer than a few days or weeks to develop.
I wrote a software project in my first CS class in my sophomore year of High School that clocked in at about 4,000 lines of code and took about 6 weeks.
In my intro CS course at college, I was assigned to write a "game of life" style simulator where the autonomous objects could be given instructions with external script files and various organisms tested against each other. That one was a 2 week project. Admittedly, a lot of the code was given to us by the instructor as seperate libraries, but the work I had to do still needed enough different classes and methods that putting it in one giant file would have been unwieldy as hell.
I don't know what CS program you went to, but I can't imagine it was very good if you only got the sort of 2-bit coding assignments that require 2 or 3 hours of effort.
