<p>I agree with the others that if someone tells/teaches you something and you think there's a flaw in that, ask/challenge them about it. That is valid about anything in life and not limited to classes in university.</p>
<p>As Owen Reynolds had said in their answer, there is often merit in doing things not the optimal way. A good example for this is bubble sort. Bubble sort is an extremely inefficient sorting algorithm and I can't think of any real life application at the top of my head. But, it is relatively easy to understand and to code. The next step is then to evaluate your code. Is it up to standards, are there better ways to do it? This is called refactoring. In real life, you rarely end up with the best solution on the first try. Often you discover hidden edge cases or other things along the way that require you to update your solution.</p>
<p>I would say that refactoring skills are one of the most important skills you can have as a programmer, because you need to be able to understand code, its implications and come up with a better solution that doesn't have those shortcomings.</p>
<p>From this perspective, I think it's a fruitful lesson to teach and talk about bubble sort. If you start with e.g. merge sort right away, you might discover bubble sort later and think &quot;oh, this looks much simpler&quot; and just use that, because you never learned why it's inefficient.</p>
<p>All in all, we can just speculate because there's no information from you, but I'd give your professor the benefit of the doubt.</p>

CC BY-SA 4.0
2024-03-26T14:24:42.263Z
A real-life application of bubble sort is distributed bubble sort. Imagine each item is sentient and able to interact with its neighbours. For instance, imagine you're asking actual people in a single queue to the cinema, to sort themselves by time of the screening they have a ticket for. What will they do? Most likely, everyone will just switch places with any person directly in front of them which has a later screening, and with any person directly behind them which has an earlier screening, until the queue of people is stable. That's distributed bubble sort.
Stef
CC BY-SA 4.0
2024-03-26T14:28:32.507Z
Also, if you take as granted that the bubble sort algorithm is correct (ie it successfully sorts any list) then it immediately follows the following theorem from group theory: [the subset of transpositions (i,i+1)](https://proofassistants.stackexchange.com/questions/2280/have-ideas-from-programming-helped-us-create-new-mathematical-proofs/2283#2283) [generates the group of permutations](https://math.stackexchange.com/questions/2521413/how-can-two-elements-of-group-s-4-generate-the-whole-group-s-4/3448424#3448424).
Stef
CC BY-SA 4.0
2024-03-26T14:43:53.123Z
@Stef yes, there are derivatives of bubble sort which include optimisations. This supports my point that learning the base version is sometimes necessary although never used in practice.
infinitezero
CC BY-SA 4.0
2024-03-26T11:46:45.420Z
2024-03-26T11:46:45.420Z
infinitezero
<p>From what I get in the comments that has nothing to do with &quot;being scientific&quot; and more to do with &quot;industry standards&quot;.</p>
<p>The truth is in pure CS you're technically just supposed to learn the general concepts, ideas and ways to tackle problems. So if that is about the mathematical or logical basis and your teacher doesn't explain them or elaborate why they are optimal and in what circumstances, you should definitely ask follow-up questions.</p>
<p>While if it's just about style and preferences or about the quirks of specific programming languages and whatnot (not the level of paradigms but implementation details), then those are elements that are changing rapidly, might be subject to personal or domain specific preferences, generally differ between programmers or whatnot. So unless the code is broken just go along with it and later do it as you prefer or as your internal style guide and whatnot advices.</p>
<p>Also you should keep in mind that &quot;optimization&quot; is not an objective criteria. It's just &quot;the best (with respect to a set of condition)&quot;. So the fastest code is likely just a list of binary commands, cutting all the unnecessary stuff and making use of all the specific quirks of the hardware that you actually work on.</p>
<p>Now if you design simulations which should really be optimized for speed or work with a fixed unalterable set of hardware where you try to get the most out of what you have, then that might make sense.</p>
<p>On the other hand if you don't have these limitations, the code may end up being hard to read, comprehend and maintain and a pain in the ass to port to any other system. So an update is likely going to come in the form of new hardware and a new software basically from scratch.</p>
<p>So with modern tech and the requirements being not about nanoseconds, but rather about &quot;not-looking-like-it's-frozen&quot; you could trade absolutely optimized time, for developer friendliness, maintainer friendliness and maybe even user friendliness. So rather than <code>wd</code> you might be able to write &quot;<code>week_days</code>&quot; and waste a few bits of memory for the extra chars of the name, but ultimately probably safe a lot of time with regards to documenting the code and have other people be able to comprehend it without a glossary.</p>
<p>On the other hand what is considered the &quot;best style&quot; and the best approach of doing something with respect to all these fuzzy objectives that aren't computable by hard science, well these could change over time anyway so you probably just need to keep up with the development anyway so zoning in on one thing might not be the best idea.</p>
<p>So from a CS perspective it's more important to know what is happening on a conceptual level and what the advantages, drawbacks and pitfalls of various methods are. So are you optimizing for memory, stability, best case, average case, worst case and so on and if you know what they do and how they do it, finding out what the best practice of implementing that is, is just looking it up.</p>

CC BY-SA 4.0
2024-03-28T13:16:50.797Z
2024-03-28T13:16:50.797Z
haxor789
<p>From your tone, I gather that you are asking about a practice that you disagree with.  Since we're speaking in extremely broad generalities, and general procedure that you could follow is:</p>
<ol>
<li>Ask the professor follow-up questions.  You are there to learn!</li>
<li>Absolutely follow the professor's advice during that course.  To do otherwise would be disrespectful.</li>
<li>Try to seek out additional sources of information, and think about how <em>you</em> would approach the issue in order to solve whatever problems the professor's technique solves later, when you are not constrained by the professor's directives.</li>
</ol>

CC BY-SA 4.0
2024-03-25T21:39:48.973Z
"2. To do otherwise would be ..." self-defeating seems a more apt adjective.
user121330
CC BY-SA 4.0
2024-03-25T21:52:10.190Z
@user121330 LOL that's a good word, too :)
Ben I.
CC BY-SA 4.0
2024-03-28T01:14:56.717Z
@BenI. I wouldn't say that not following a teacher's advice is disrespectful. If you have your own way of doing something, and they give you some advice of something to do, sure, you should try it (not doing so is disrespectful for sure), but it you don't think it works as well as what you were already doing, don't keep trying.
DaemonsMercy
CC BY-SA 4.0
2024-03-28T11:00:18.843Z
@Daemonic It would also depend on whether it's advice or a requirement. I've had teachers where something like this would be a hard requirement. Not following it would result in you failing the class. If it's just advice on how they think it can be done better, absolutely see if it works for you, but if it doesn't, you don't have to follow it.
Dnomyar96
CC BY-SA 4.0
2024-03-25T13:00:18.330Z
2024-03-25T14:50:12.473Z
2024-03-25T14:50:12.473Z
Ben I.
<p>There is a misunderstanding here: The &quot;scientific method&quot; has nothing to do with &quot;methods&quot; taught in CS.</p>
<p>The scientific method, in the shortest possible explanation, means that statements about reality need to be falsifiable - and that all those statements are only to be considered &quot;true&quot; until falsified.</p>
<p>Methods in CS are practical precepts of how to solve whatever problem at hand. These kinds of problems are (for sure in an environment where there is a teacher in front of a class) <em>not</em> unsolved problems of how the universe works, but simple tasks designed to allow pupils to practice whatever toolset they have been taught so far.</p>
<p>Asking whether a CS teacher is being &quot;scientific&quot; is a category error - it simply makes no sense.</p>
<p>As to your underlying question: no, your teacher has to prove nothing to you. He is there to enable you to learn facts and practices which give you a tiny, initial peek into what CS is about. What that is is not like following a tutorial on the 'net or some web site. Whatever he is teaching is very likely structured more along didactic lines then what is &quot;best practice&quot;. It is most likely mostly designed to get you thinking in CS terms to be able to come up with your own solutions later. It is very unlikely that you will actually use anything you learned in school verbatim later in your professional life.</p>
<p>From a business perspective, if I employ someone fresh out of school or uni, I would not expect them to know even the tiniest bit of practice relevant to what we are doing in the real world. We are also not solving scientific problems; we are creating software, or building technical solutions (cloud stuff etc.). There is very little science involved.</p>
<p>If you use CS for actual science work (i.e., building some simulation as a physicist to work out some theories), then the science is what you are going while writing your paper; not the software you are building. The software is, at best, a practical application or demonstration of your theory, not even a scientific proof (<em>that</em> can only come from observing reality).</p>
<p>If the science you are working on is actual CS, for example, you want to invent a new sorting algorithm or something along those lines, then of course the programm you write after thinking long and hard about it is more &quot;scientific&quot; in that it <em>may</em> be the actual experiment which proves or disproves your new theory, but then again I can think of only very few instances where such a program would be considered a scientific proof for anything - actual proofs are, even in CS, mostly something you do with your brain, pen and paper. Importantly, this kind of stuff is not part of any curriculum where a teacher stands in front of a class; this would be PhD material.</p>
<p>All of this is for practical CS courses (where methods are actually taught). If you are in a Theoretical CS course, you will mostly be learning math-like definitions, axioms and proofs based on them - they also do not follow the scientific method per se, but build a mathematical/logical building which is open to inspection for everyone. If you believe, in a Theoretical CS course, that something is wrong, then your best recourse is to ask the teacher to explain it again. It is incredibly likely that you simply misunderstood (partly due to maybe missing some facts still).</p>

CC BY-SA 4.0
2024-03-27T10:17:42.963Z
2024-03-27T10:26:14.673Z
2024-03-27T10:26:14.673Z
AnoE
<p>My opinion, which seemed to work pretty well while I taught, is that in-class examples should never be &quot;best practice&quot;. Learning ComSci is like learning to drive in a big empty parking lot, then on empty streets; or hammering nails into just a board at first -- it's better to learn the basics without a lot of distractions.</p>
<p>One problem is that &quot;real world&quot; examples blow up with details until they take too much time and make no sense. I've seen textbooks with try/catch error-detection around every example, or preferring member function examples over plain functions. Here's a decent example of a cascading-if which would never be used in practice:</p>
<pre><code>if n==1 print(&quot;one&quot;)
else if n==2 print(&quot;two)
else if n==3 {
  print(&quot;three&quot;)
}
else ...
</code></pre>
<p>We could search for a real example, but it might use enumerated types ( which haven't been covered in class yet) and maybe the real thing it deals with is tristrips vs. quads vs. quadstrips in GPU graphics - making it very long, hard to read and impossible for students to try it on their own.</p>
<p>Another problem is that best practices change plenty over time and place. Time-wise we went from needing to know Design Patterns in an interview to &quot;Design Patterns are Ruining Code&quot;. We went from checking pre-conditions to try-catch to adding a new &quot;throws&quot; annotation. And for style (how to name variables, etc...) -- who knows. Place-wise you'll see programming Q's here where one person's solution is another's &quot;I'd be fired if I wrote code like that&quot;.</p>
<p>But most important, I feel, is programming is more like math. Maybe we drill on things like 7x4, but there aren't flash cards for &quot;4x^2+5x-6&quot;. You learn the factoring trick. Once you know how to factor, integrate by parts, and so on, you can attack new math problems with a combination. And those tricks are learned using abstract non-real-world examples. Many programming problems are the same. Once someone has used simple examples to learn if's, loops, lists, nested loops, classes... they'll know how to break up a big problems into &quot;use a list for this&quot; and so on.</p>
<p>Put another way, coding bootcamps emphasize solving real-world problems. And a criticism is that their graduates can only do those exact things, and aren't so great at new stuff.</p>

CC BY-SA 4.0
2024-03-26T15:12:15.587Z
"which would never be used in practice"... if only. +1 though.
David
CC BY-SA 4.0
2024-03-26T20:47:57.067Z
"in-class examples should never be "best practice"" And this is why some many examples of bad practices exist in real life today... I guess I shouldn't blame students for doing what they were taught.... I do. But I shouldn't. The CS teachers are really the people to blame....
Questor
CC BY-SA 4.0
2024-03-27T08:35:03.327Z
@Questor: I think it's less that they aren't the "Best practice you'll always need to abide by" - depending on the level of the given course, it is common for someone to focus on the syntax, and then the algorithms that can help with a task, before we focus on "Make every variable a symbolic constant", and "Make sure that you're never four levels of indentation deep"; chances are, the best practice will change, and then you'll have to adapt to that new best practice - but the other things will transfer. And you'll learn to break a best practice when it's necessary (See: SRP vs Singletons.).
Alexander The 1st
CC BY-SA 4.0
2024-03-28T14:03:14.240Z
"we went from needing to know Design Patterns in an interview to "Design Patterns are Ruining Code"" First time I'm hearing that! And from the comment it sounds ubiquitous. Got any links or anything to read more on that? I'm curious to learn why people are allegedly thinking that nowadays
kirgod
CC BY-SA 4.0
2024-03-28T16:30:41.163Z
@kirgod Ha! I've done that -- assumed something was obscure enough I'd need a link. But in this case googling "design patterns are ruining code" is a flood.
Owen Reynolds
CC BY-SA 4.0
2024-03-28T16:37:21.017Z
@David I thought about mentioning how practical "best practice" often involves about 15% hack-tastic fixes to get it working, but that seemed a bit off-the-track. I mean, I once pasted in a selection sort to handle parallel arrays, and it was fine.
Owen Reynolds
CC BY-SA 4.0
2024-03-28T19:09:34.983Z
@OwenReynolds I googled it indeed, and got people asking in reddit, quora, and stackoverflow. Actual articles (or columns) were only about 3, one of them being on anti patterns, one about rethinking design patterns (the preview saying people often misuse patterns), and the rest of the results being guides on design patterns. I guess it's not really that common if the majority of search results for "design patterns are ruining code" are guides on how to use design patterns. If you have any proper articles on the topic outside of "google it", I'd be happy to read them!
kirgod
CC BY-SA 4.0
2024-03-26T00:17:16.733Z
2024-03-26T00:17:16.733Z
Owen Reynolds
<blockquote>
<p>&quot;but not the best possible practice&quot;</p>
</blockquote>
<p>And you of course know what the best possible practice is. On a side note you might want to look up the <a href="https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect" rel="noreferrer">dunning kruger effect</a>.</p>
<h2>There are best practices... and there are best practices.</h2>
<h3>Engineering best practices.</h3>
<p>Always use library methods instead of making your own. Don't reinvent the wheel etc...</p>
<p>None of which are followed in CS classes because you want students to learn how to write a bubble sort, quicksort, merge sort, binary tree, etc... because the experience of building those algorithms makes for a better programmer.</p>
<h3>style best practices</h3>
<p>Such as using descriptive names for variables, and methods. And not using magic numbers... And yes <code>const int FIVE = 5;</code> is still a magic number. where as <code>const int WEEK_WORK_DAYS = 5</code> is not a magic number. Because FIVE doesn't have a meaning attached to it.</p>
<p>Some of those don't really matter such as:</p>
<ul>
<li>Spaces instead of tabs (unless you think tabs are better, in which case Die Heretic Scum).</li>
<li>Or how to place curly brackets.</li>
<li>The number of spaces in an indent (3,4... just be consistent).</li>
<li>snake_case vs camelCase vs CamelCase (again just be consistent).</li>
<li>This list is really long...</li>
</ul>
<p>The biggest style best practice is of course what your customer IE the professor tells you to do. As long as your code is readible and maintainable...</p>
<p>The customer is &quot;always right on matters of style&quot; after all</p>
<h3>There are good design practices, or perhaps best known method:</h3>
<p>I would read stuff by Robert C. Martin for a better answer then I want to put in a here... But basically it boils down to decouple your stuff. Write unit tests where possible. Write integration tests. Write functional tests. Don't have code behavior rely on hidden state (avoid global variables) if at all possible... Etc.</p>
<p>Use design patterns that make sense for the problem you are solving. E.G. don't hammer in screws.</p>

CC BY-SA 4.0
2024-03-28T16:39:22.257Z
I think the right answer depends on the level of class. In mine I assumed it was freshman programming, you seem to be assuming it's jr. level software engineering. The Q is labelled intro, but then they talk about test cases, so who knows.
Owen Reynolds
CC BY-SA 4.0
2024-03-26T21:22:25.973Z
2024-03-26T21:38:58.413Z
2024-03-26T21:38:58.413Z
Questor
<p>Is it normal that a computer science educator teaches something and gives no reference nor proof that his method is useful? What should a student do if he was taught something that sounds useful but not the best possible practice?</p>

CC BY-SA 4.0
2024-03-25T16:22:51.557Z
Do you have an example?
ggorlen
CC BY-SA 4.0
2024-03-25T23:24:33.333Z
There are parts of a computer science education that are science-like (or at least, effectively mathematics). Lots of it is basically trade school skills (learning the syntax of languages, specific APIs and compiler toolsets, etc.). You're going to need to give an example for the answers to be anything more than generalities that may have no bearing whatsoever on your actual concern.
ShadowRanger
CC BY-SA 4.0
2024-03-26T14:30:27.517Z
@ggorlen The example is that the lecturer said that one should put test code as a comment above the method, as it is clearer that there is a test for all methods. I thought it would be useful to put tests in a separate file so that testers and developers can work separately, although in this course we write code and tests individually.
guest
CC BY-SA 4.0
2024-03-26T14:50:58.130Z
@guest That sounds an awful lot like a course-specific requirement or instructor preference. It wouldn't be common in industry, but it would make grading so much easier.
ojchase
CC BY-SA 4.0
2024-03-26T15:54:06.363Z
@guest Thanks. Can you [edit] the post to provide that context? Showing an actual example of the code you're discussing might help. How would test code execute if it's in a comment? Or are you referring to [Python's doctest](https://docs.python.org/3/library/doctest.html)? Whether something is good practice or not often depends on these details. I understand you're asking generally, but starting with specifics, then moving general is a good approach.
ggorlen
CC BY-SA 4.0
2024-03-26T16:41:41.850Z
I'm not seeing that your example is "non-scientific" at all.
Jon Custer
CC BY-SA 4.0
2024-03-26T17:47:11.103Z
Also, how would one "prove" (in a mathematical sense) that one way of testing is better than another? Or if you're not referring to a mathematical proof, what evidence are you expecting? How did you come to the conclusion that the teacher's approach isn't best practice?
ggorlen
CC BY-SA 4.0
2024-03-27T00:18:54.210Z
@ojchase In both Python and Rust, doctests are fairly common.
wizzwizz4
CC BY-SA 4.0
2024-03-27T14:48:05.897Z
There's a big difference between "science" and "best practice", since much practical computer programming and software engineering is based on tradition rather than science.
Barmar
CC BY-SA 4.0
2024-03-28T19:14:57.017Z
It sounds like the OP isn't a fan of the teacher and is looking for an excuse to make them look bad, or OP may be suffering from Dunning-Kruger, thinking that they know a "better" method than the teacher just because they're used to doing things differently and doesn't want to adapt?
kirgod
<introductory-lesson>
Should a cs teacher teach non-scientific methods?
# Should a cs teacher teach non-scientific methods?

(Asked by: username_0 on 2024-03-25)

Is it normal that a computer science educator teaches something and gives no reference nor proof that his method is useful? What should a student do if he was taught something that sounds useful but not the best possible practice?

**Tags:** introductory-lesson

> **Comments:**
> **username_1**: Do you have an example?  
> **username_2**: There are parts of a computer science education that are science-like (or at least, effectively mathematics). Lots of it is basically trade school skills (learning the syntax of languages, specific APIs and compiler toolsets, etc.). You're going to need to give an example for the answers to be anything more than generalities that may have no bearing whatsoever on your actual concern.  
> **username_0**: @username_1 The example is that the lecturer said that one should put test code as a comment above the method, as it is clearer that there is a test for all methods. I thought it would be useful to put tests in a separate file so that testers and developers can work separately, although in this course we write code and tests individually.  
> **username_3**: @username_0 That sounds an awful lot like a course-specific requirement or instructor preference. It wouldn't be common in industry, but it would make grading so much easier.  
> **username_1**: @username_0 Thanks. Can you [edit] the post to provide that context? Showing an actual example of the code you're discussing might help. How would test code execute if it's in a comment? Or are you referring to [Python's doctest](https://docs.python.org/3/library/doctest.html)? Whether something is good practice or not often depends on these details. I understand you're asking generally, but starting with specifics, then moving general is a good approach.  
> **username_4**: I'm not seeing that your example is "non-scientific" at all.  
> **username_1**: Also, how would one "prove" (in a mathematical sense) that one way of testing is better than another? Or if you're not referring to a mathematical proof, what evidence are you expecting? How did you come to the conclusion that the teacher's approach isn't best practice?  
> **username_5**: @username_3 In both Python and Rust, doctests are fairly common.  
> **username_6**: There's a big difference between "science" and "best practice", since much practical computer programming and software engineering is based on tradition rather than science.  
> **username_7**: It sounds like the OP isn't a fan of the teacher and is looking for an excuse to make them look bad, or OP may be suffering from Dunning-Kruger, thinking that they know a "better" method than the teacher just because they're used to doing things differently and doesn't want to adapt?  

---

## 6 answers

### Answer by username_11 on 2024-03-25. Score: 16 | Accepted answer

From your tone, I gather that you are asking about a practice that you disagree with. Since we're speaking in extremely broad generalities, and general procedure that you could follow is:

1. Ask the professor follow-up questions. You are there to learn!
2. Absolutely follow the professor's advice during that course. To do otherwise would be disrespectful.
3. Try to seek out additional sources of information, and think about how *you* would approach the issue in order to solve whatever problems the professor's technique solves later, when you are not constrained by the professor's directives.

> **Comments:**
> **username_12**: "2. To do otherwise would be ..." self-defeating seems a more apt adjective.  
> **username_11**: @username_12 LOL that's a good word, too :)  
> **username_13**: @BenI. I wouldn't say that not following a teacher's advice is disrespectful. If you have your own way of doing something, and they give you some advice of something to do, sure, you should try it (not doing so is disrespectful for sure), but it you don't think it works as well as what you were already doing, don't keep trying.  
> **username_14**: @Daemonic It would also depend on whether it's advice or a requirement. I've had teachers where something like this would be a hard requirement. Not following it would result in you failing the class. If it's just advice on how they think it can be done better, absolutely see if it works for you, but if it doesn't, you don't have to follow it.  

---

### Answer by username_16 on 2024-03-26. Score: 13

My opinion, which seemed to work pretty well while I taught, is that in-class examples should never be "best practice". Learning ComSci is like learning to drive in a big empty parking lot, then on empty streets; or hammering nails into just a board at first -- it's better to learn the basics without a lot of distractions.
One problem is that "real world" examples blow up with details until they take too much time and make no sense. I've seen textbooks with try/catch error-detection around every example, or preferring member function examples over plain functions. Here's a decent example of a cascading-if which would never be used in practice:
if n==1 print("one")
else if n==2 print("two)
else if n==3 {
  print("three")
}
else ...

We could search for a real example, but it might use enumerated types ( which haven't been covered in class yet) and maybe the real thing it deals with is tristrips vs. quads vs. quadstrips in GPU graphics - making it very long, hard to read and impossible for students to try it on their own.
Another problem is that best practices change plenty over time and place. Time-wise we went from needing to know Design Patterns in an interview to "Design Patterns are Ruining Code". We went from checking pre-conditions to try-catch to adding a new "throws" annotation. And for style (how to name variables, etc...) -- who knows. Place-wise you'll see programming Q's here where one person's solution is another's "I'd be fired if I wrote code like that".
But most important, I feel, is programming is more like math. Maybe we drill on things like 7x4, but there aren't flash cards for "4x^2+5x-6". You learn the factoring trick. Once you know how to factor, integrate by parts, and so on, you can attack new math problems with a combination. And those tricks are learned using abstract non-real-world examples. Many programming problems are the same. Once someone has used simple examples to learn if's, loops, lists, nested loops, classes... they'll know how to break up a big problems into "use a list for this" and so on.
Put another way, coding bootcamps emphasize solving real-world problems. And a criticism is that their graduates can only do those exact things, and aren't so great at new stuff.

> **Comments:**
> **username_17**: "which would never be used in practice"... if only. +1 though.  
> **username_18**: "in-class examples should never be "best practice"" And this is why some many examples of bad practices exist in real life today... I guess I shouldn't blame students for doing what they were taught.... I do. But I shouldn't. The CS teachers are really the people to blame....  
> **username_19**: @username_18: I think it's less that they aren't the "Best practice you'll always need to abide by" - depending on the level of the given course, it is common for someone to focus on the syntax, and then the algorithms that can help with a task, before we focus on "Make every variable a symbolic constant", and "Make sure that you're never four levels of indentation deep"; chances are, the best practice will change, and then you'll have to adapt to that new best practice - but the other things will transfer. And you'll learn to break a best practice when it's necessary (See: SRP vs Singletons.).  
> **username_7**: "we went from needing to know Design Patterns in an interview to "Design Patterns are Ruining Code"" First time I'm hearing that! And from the comment it sounds ubiquitous. Got any links or anything to read more on that? I'm curious to learn why people are allegedly thinking that nowadays  
> **username_16**: @username_7 Ha! I've done that -- assumed something was obscure enough I'd need a link. But in this case googling "design patterns are ruining code" is a flood.  
> **username_16**: @username_17 I thought about mentioning how practical "best practice" often involves about 15% hack-tastic fixes to get it working, but that seemed a bit off-the-track. I mean, I once pasted in a selection sort to handle parallel arrays, and it was fine.  
> **username_7**: @OwenReynolds I googled it indeed, and got people asking in reddit, quora, and stackoverflow. Actual articles (or columns) were only about 3, one of them being on anti patterns, one about rethinking design patterns (the preview saying people often misuse patterns), and the rest of the results being guides on design patterns. I guess it's not really that common if the majority of search results for "design patterns are ruining code" are guides on how to use design patterns. If you have any proper articles on the topic outside of "google it", I'd be happy to read them!  

---

### Answer by username_15 on 2024-03-27. Score: 9

There is a misunderstanding here: The "scientific method" has nothing to do with "methods" taught in CS.

The scientific method, in the shortest possible explanation, means that statements about reality need to be falsifiable - and that all those statements are only to be considered "true" until falsified.

Methods in CS are practical precepts of how to solve whatever problem at hand. These kinds of problems are (for sure in an environment where there is a teacher in front of a class) *not* unsolved problems of how the universe works, but simple tasks designed to allow pupils to practice whatever toolset they have been taught so far.

Asking whether a CS teacher is being "scientific" is a category error - it simply makes no sense.

As to your underlying question: no, your teacher has to prove nothing to you. He is there to enable you to learn facts and practices which give you a tiny, initial peek into what CS is about. What that is is not like following a tutorial on the 'net or some web site. Whatever he is teaching is very likely structured more along didactic lines then what is "best practice". It is most likely mostly designed to get you thinking in CS terms to be able to come up with your own solutions later. It is very unlikely that you will actually use anything you learned in school verbatim later in your professional life.

From a business perspective, if I employ someone fresh out of school or uni, I would not expect them to know even the tiniest bit of practice relevant to what we are doing in the real world. We are also not solving scientific problems; we are creating software, or building technical solutions (cloud stuff etc.). There is very little science involved.

If you use CS for actual science work (i.e., building some simulation as a physicist to work out some theories), then the science is what you are going while writing your paper; not the software you are building. The software is, at best, a practical application or demonstration of your theory, not even a scientific proof (*that* can only come from observing reality).

If the science you are working on is actual CS, for example, you want to invent a new sorting algorithm or something along those lines, then of course the programm you write after thinking long and hard about it is more "scientific" in that it *may* be the actual experiment which proves or disproves your new theory, but then again I can think of only very few instances where such a program would be considered a scientific proof for anything - actual proofs are, even in CS, mostly something you do with your brain, pen and paper. Importantly, this kind of stuff is not part of any curriculum where a teacher stands in front of a class; this would be PhD material.

All of this is for practical CS courses (where methods are actually taught). If you are in a Theoretical CS course, you will mostly be learning math-like definitions, axioms and proofs based on them - they also do not follow the scientific method per se, but build a mathematical/logical building which is open to inspection for everyone. If you believe, in a Theoretical CS course, that something is wrong, then your best recourse is to ask the teacher to explain it again. It is incredibly likely that you simply misunderstood (partly due to maybe missing some facts still).


---

### Answer by username_18 on 2024-03-26. Score: 6

> "but not the best possible practice"

And you of course know what the best possible practice is. On a side note you might want to look up the [dunning kruger effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect).

## There are best practices... and there are best practices.

### Engineering best practices.

Always use library methods instead of making your own. Don't reinvent the wheel etc...

None of which are followed in CS classes because you want students to learn how to write a bubble sort, quicksort, merge sort, binary tree, etc... because the experience of building those algorithms makes for a better programmer.

### style best practices

Such as using descriptive names for variables, and methods. And not using magic numbers... And yes `const int FIVE = 5;` is still a magic number. where as `const int WEEK_WORK_DAYS = 5` is not a magic number. Because FIVE doesn't have a meaning attached to it.

Some of those don't really matter such as:

* Spaces instead of tabs (unless you think tabs are better, in which case Die Heretic Scum).
* Or how to place curly brackets.
* The number of spaces in an indent (3,4... just be consistent).
* snake\_case vs camelCase vs CamelCase (again just be consistent).
* This list is really long...

The biggest style best practice is of course what your customer IE the professor tells you to do. As long as your code is readible and maintainable...

The customer is "always right on matters of style" after all

### There are good design practices, or perhaps best known method:

I would read stuff by Robert C. Martin for a better answer then I want to put in a here... But basically it boils down to decouple your stuff. Write unit tests where possible. Write integration tests. Write functional tests. Don't have code behavior rely on hidden state (avoid global variables) if at all possible... Etc.

Use design patterns that make sense for the problem you are solving. E.G. don't hammer in screws.

> **Comments:**
> **username_16**: I think the right answer depends on the level of class. In mine I assumed it was freshman programming, you seem to be assuming it's jr. level software engineering. The Q is labelled intro, but then they talk about test cases, so who knows.  

---

### Answer by username_8 on 2024-03-26. Score: 1

I agree with the others that if someone tells/teaches you something and you think there's a flaw in that, ask/challenge them about it. That is valid about anything in life and not limited to classes in university.

As username_16 had said in their answer, there is often merit in doing things not the optimal way. A good example for this is bubble sort. Bubble sort is an extremely inefficient sorting algorithm and I can't think of any real life application at the top of my head. But, it is relatively easy to understand and to code. The next step is then to evaluate your code. Is it up to standards, are there better ways to do it? This is called refactoring. In real life, you rarely end up with the best solution on the first try. Often you discover hidden edge cases or other things along the way that require you to update your solution.

I would say that refactoring skills are one of the most important skills you can have as a programmer, because you need to be able to understand code, its implications and come up with a better solution that doesn't have those shortcomings.

From this perspective, I think it's a fruitful lesson to teach and talk about bubble sort. If you start with e.g. merge sort right away, you might discover bubble sort later and think "oh, this looks much simpler" and just use that, because you never learned why it's inefficient.

All in all, we can just speculate because there's no information from you, but I'd give your professor the benefit of the doubt.

> **Comments:**
> **username_9**: A real-life application of bubble sort is distributed bubble sort. Imagine each item is sentient and able to interact with its neighbours. For instance, imagine you're asking actual people in a single queue to the cinema, to sort themselves by time of the screening they have a ticket for. What will they do? Most likely, everyone will just switch places with any person directly in front of them which has a later screening, and with any person directly behind them which has an earlier screening, until the queue of people is stable. That's distributed bubble sort.  
> **username_9**: Also, if you take as granted that the bubble sort algorithm is correct (ie it successfully sorts any list) then it immediately follows the following theorem from group theory: [the subset of transpositions (i,i+1)](https://proofassistants.stackexchange.com/questions/2280/have-ideas-from-programming-helped-us-create-new-mathematical-proofs/2283#2283) [generates the group of permutations](https://math.stackexchange.com/questions/2521413/how-can-two-elements-of-group-s-4-generate-the-whole-group-s-4/3448424#3448424).  
> **username_8**: @username_9 yes, there are derivatives of bubble sort which include optimisations. This supports my point that learning the base version is sometimes necessary although never used in practice.  

---

### Answer by username_10 on 2024-03-28. Score: 0

From what I get in the comments that has nothing to do with "being scientific" and more to do with "industry standards".

The truth is in pure CS you're technically just supposed to learn the general concepts, ideas and ways to tackle problems. So if that is about the mathematical or logical basis and your teacher doesn't explain them or elaborate why they are optimal and in what circumstances, you should definitely ask follow-up questions.

While if it's just about style and preferences or about the quirks of specific programming languages and whatnot (not the level of paradigms but implementation details), then those are elements that are changing rapidly, might be subject to personal or domain specific preferences, generally differ between programmers or whatnot. So unless the code is broken just go along with it and later do it as you prefer or as your internal style guide and whatnot advices.

Also you should keep in mind that "optimization" is not an objective criteria. It's just "the best (with respect to a set of condition)". So the fastest code is likely just a list of binary commands, cutting all the unnecessary stuff and making use of all the specific quirks of the hardware that you actually work on.

Now if you design simulations which should really be optimized for speed or work with a fixed unalterable set of hardware where you try to get the most out of what you have, then that might make sense.

On the other hand if you don't have these limitations, the code may end up being hard to read, comprehend and maintain and a pain in the ass to port to any other system. So an update is likely going to come in the form of new hardware and a new software basically from scratch.

So with modern tech and the requirements being not about nanoseconds, but rather about "not-looking-like-it's-frozen" you could trade absolutely optimized time, for developer friendliness, maintainer friendliness and maybe even user friendliness. So rather than `wd` you might be able to write "`week_days`" and waste a few bits of memory for the extra chars of the name, but ultimately probably safe a lot of time with regards to documenting the code and have other people be able to comprehend it without a glossary.

On the other hand what is considered the "best style" and the best approach of doing something with respect to all these fuzzy objectives that aren't computable by hard science, well these could change over time anyway so you probably just need to keep up with the development anyway so zoning in on one thing might not be the best idea.

So from a CS perspective it's more important to know what is happening on a conceptual level and what the advantages, drawbacks and pitfalls of various methods are. So are you optimizing for memory, stability, best case, average case, worst case and so on and if you know what they do and how they do it, finding out what the best practice of implementing that is, is just looking it up.


---

