I'm attempting to provide an agnostic means of identifying a member. I need a nickname, a guid, and one of user_id, email, or phone_number. Since I'm using Python, I try to not care about the Python type of member because, after all, if it has what I'm looking for then I don't really care whether...
> The question is, if my attempts to not care about the type to this extent are reasonable, then is there a way to make this code better adhere to the principle of DRY?
Sounds on-topic to me
> how do I write ducktyping, by the way, here's my code that sort of works!
Sounds off-topic to me, but I don't interpret the question the same way apparently
> Well, when you say it this way it's off topic, but saying the same thing that way is on.
I understand semantics is a big part of the conversation, rightfully and necessarily, but...
Well, it's like I said earlier. If the way a question is stated is the issue, it can be edited to be on topic.
Now, that doesn't mean that the plain English isn't important. It is. It's the intent behind the question. So it matters, but people may need some gentle prodding to learn how to write a good question.
Yea. Plain English part differentiates mediocre on topic questions from great on-topic questions, but given that a chunk of code with very little plain English is on-topic, it's weird that some non-code phrases make it off-topic.
In that regard, particularly if English is not your first language, there's almost incentive to post less plain-English.
Better to be mediocre and on-topic than to be off topic.
Sometimes I think it might just be a case of bad formulation. You might want just an ordinary CR-style review, but you might formulate yourself differently, so that someone considers your request off-topic for one reason or another.
I think sometimes we over-analyze what the OP actually is asking for
OK, so what you are saying is that we review the code as the code is presented, and any surrounding text is just hints and suggestions and descriptions of what the code is and it's context?
I'm attempting to provide an agnostic means of identifying a member. I need a nickname, a guid, and one of user_id, email, or phone_number. Since I'm using Python, I try to not care about the Python type of member because, after all, if it has what I'm looking for then I don't really care whether...
> The question is, if my attempts to not care about the type to this extent are reasonable, then is there a way to make this code better adhere to the principle of DRY?
If some Python reviewer starts reading the code and makes the conclusion: "This is not working properly", then they have two options: 1. Add a comment and VTC. 2. Post an answer addressing common CR issues and point out the flaw
I have written some code using RESTEasy to handle RESTful service calls and parse the response XML into relevant JAXB annotated classes. At the moment I have seperate methods for each return type:
public class RestBase {
protected final RestClient restClient;
public RestBase() {
...
@RubberDuck I think the original code works as intended, but he wants to improve it (the cleaniness, not what it does) - but while attempting to improve it he failed.
I have written a parallelized version of Gauss-Laguerre quadrature and am wondering how best to handle infinities that occur due to lack of floating-point precision.
Basically, I use Newton's method to approximately solve Laguerre polynomials in order to find the abscissae \$x_{i}\$ and weights...
> I have written a parallelized version of Gauss-Laguerre quadrature and am wondering how best to handle infinities that occur due to lack of floating-point precision.
> I was wondering what design strategy I should take in this approach (bearing in mind that f(x) is user-defined and thus may use NaN as infinity; for instance the following might be used
But, the issue you guys say, is that he has code, and the text is not important
(as important)
And I am saying that a code review is meaningless to the asker because that is not what he wants.
so, a good code review, assuming the 'design' is right, would be of low value.
Editing the question to say: "here's my code that does XXX, please review?", will make the question on topic, but it does not change the asker's intentions.
But, if someone were to challenge my decision to close it as off-topic/too broad, I have no grounds to defend it.... at the moment
@SimonAndréForsberg For the current design, yes.
for the future design that solves the problem in a way that is better, no.
that is my argument all along, that the code is not ready for review.
and the critical component that has to be 'settled' is the design, before we can even consider the code for review..... and, if he came and said: here's my code....
and we said, well, you are not handling NaN right, and that you chould change your design.....
then we can review the design in a code review, but he can't ask for a discussion about whether the design is the best.
an asker has to know what they are trying to accomplish before any code they present is known to be working.
Yes. So, how I see it. The difference between that question and mine is his question asks "How should I go about doing this?", where mine said, "This is how I did it? I don't think I did it best. Can it be better?"
@rolfl Again, I disagree about the "design" thing. I think this C++ math question wants to change what his code does, not how it does it. To me, design is not about what the code does.
@RubberDuck With emphasis on thinking of doing this. I.e. he hasn't done it that way yet.
I am open to suggestions, but bringing it back to the FizzBuzz example, it is OK to say "I did it this way, is it OK", but it is not OK to say "should I use %15 and String constants or should I use %3 and %5 and concatenate Fizz and Buzz, by the way, here is how I have it now?"
@rolfl Disagree. Using %15 and String consts or %3 and %5 is about the how, not the what. As long as there is a working version that does the same thing, that's fine by me. (Usually, can't think of an exception right now at least)
Yeah. Bad example. So, let's reign this in a little. We keep drifting.
This all started with Interface only questions, right? Did we ever land anywhere on that?
Let's eat this elephant one bite at a time.
To summarize that, a lot of us feel Interfaces are on topic only if they're accompanied by an implementation. Some of us feel that they're on topic without one, but are a low quality question without it. Some feel they're just plain off topic as "Example Code".
My issue with API only questions is that they are basically saying "how do I create an API that's good", because essentially anything but style and indentation changes to an interface changes "what the interface does".
since that is the entire purpose of the interface, changing it, is changing the purpose.
It is OK to ask does my code implement the interface well, but it is another thing to say "what should my code look like?"
@SimonAndréForsberg The problem is solved; this is more of an edge case which I am asking for advice on how to handle? I get very confused where it is acceptable to ask these sorts of questions due to the large number of related SE sites (SO, Programmers, CS.SE, Math.SE, etc.); but if you think it would be better for CS.SE then I will move it! :) — Shaktal17 mins ago
I read from here that quicksort can be tail optimized. I tested the code given and it didn't work:
TAIL-RECURSIVE-QUICKSORT(A, p, r)
while p < r
q = PARTITION(A, p, r)
if q < (p + (r-p)/2)
TAIL-RECURSIVE-QUICKSORT(A, p, q-1)
p = q+1
else
TAIL-RECURSIVE-QU...
I have written some code using RESTEasy to handle RESTful service calls and parse the response XML into relevant JAXB annotated classes. At the moment I have seperate methods for each return type:
public class RestBase {
protected final RestClient restClient;
public RestBase() {
...
I have written a parallelized version of Gauss-Laguerre quadrature and am wondering how best to handle infinities that occur due to lack of floating-point precision.
Basically, I use Newton's method to approximately solve Laguerre polynomials in order to find the abscissae \$x_{i}\$ and weights...
I read from here that quicksort can be tail optimized. I tested the code given and it didn't work:
TAIL-RECURSIVE-QUICKSORT(A, p, r)
while p < r
q = PARTITION(A, p, r)
if q < (p + (r-p)/2)
TAIL-RECURSIVE-QUICKSORT(A, p, q-1)
p = q+1
else
TAIL-RECURSIVE-QU...
Code Review - Discussion about help v…
Code Review - Discussion about help v…