7 kyu
Building blocks
3,918 of 13,017NaMe613
Loading description...
Object-oriented Programming
Fundamentals
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Cant pass Submit because in the Test (Java) assertEquals has no tolerence values.
Are you sure that the missing tolerance is a problem here? Dimensions of a block are integers, no tolerance should be necessary.
I edited the tolerance in the "small test" below (just 0.1) and the small test worked fine. Maybe its another problem with my solution, but the error whats showing up when i want to submit is "Use assertEquals(expected, actual, delta) to compare floating-point numbers".
this is because you defined all the methods of your class as returning
floats. while it is true that the return type is not specified in the description, since all the input dimensions are integers, it makes no sense to return afloat, as there are no divisions involved. this is a problem with your code and not a kata issue, but you may open a suggestion asking for the description to mention thisthe markdown in the description mixes code blocks with language blocks, resulting in confusing rendering, e.g.:
either the languages tags should be replaced by conditional ones, or the backticks surrounding function names should be erased and the specification commented out
A random test failed if I make check whether values of width, length and height are positive
The description explicitly stated that error checking is not necessary:
Resolving...
This comment has been hidden.
This comment has been hidden.
Oops, I've jsut realised that I forgot to take the first line out of my constructor in my first comment. I used it to debug but it has no impact on the problem.
That line:
you are confused about the syntax of a constructor in Java. constructors have no return type. by providing a return type
void, you are not creating a constructor but a methodBlockin the classBlock, which is unusual but allowed by the language. and then the tests crash because they cannot find the expected constructorRust translation
Approved by someone
Getters and setters are the two worst ideas in software engineering.
Please do explain further, as I would like to progress from being a getter-setter.
This comment has been hidden.
Why can't the length be shorter than the width??? As long as they're all positive, their relative values shouldn't matter. The terms width/length/height are just arbitrary labels for orthogonal scalars. I ran my solution against the inputs (5, 3, 6) and had no error. What's there to fix?
For javascript : since the Class syntactic sugar is suggested, why not go the full length and use getters too ?
I spent more time moving variables around to make the randomTest case work than I spent actually solving the problem.
C# should probably also be changed to match convention... unlike Java GetX() methods aren't the way accessors are written in C#, so practicing this in C# should probably use properties instead.
You're right,
however the point of this kata is to create a simple class with some methods not a best practice class.
Aside from that, considering how many people have done this kata it's a bit to late to change : )
That make sense! Also with so many languages for this kata it might be confusing if they were too different.
Ruby and Python need to be changed to match convention. Perhaps CoffeeScript as well.
I think in python the kata does force you to write non-pythonic way. Getter (and setter) are more Java style, I guess pythonist would prefer having @property :) Otheriwse, it's a simple a fun kata :)
My code in Java is working fine on tests, however it's failing on a random test with a large number and without knowing what the values were I can't pass. Is this a problem with the tests or with my code?
This comment has been hidden.
This comment has been hidden.
It looks like your getSurfaceArea method is problematic. What's the SA of a cube? How about a rectangular box?
So I need to modify this to account for a regular box rather than a cube?
I am baffled. Why are submission for JS with ECMA6 considered best practice? Even on MDN there are many TBD sections, it was finalized in June 2015. IE doesn't support it, Android support is ... probably nonexistent. Do you precompile JavaScript before deploying or what?
I'm having my code pass the test cases just fine but am getting caught up in the main submission with an (Expected: 3, instead got: 1) error. I tried changing around the 'data array' position that the various measures (width et c) were reading and got the first submission test to clear but then the second test was failing.
Is this a problem with my code or in the submission tests?
which language ?
javascript
First test creates 2 blocks and asks for values of 1st one. Your error message
Expected: 3, instead got: 1indicates the 2d block you created crashed data of 1st one. (3is value of 1st Block width,1is value of 2d Block width)So it seems the problem is with your code. Good luck!
Great, this should help me. Thanks.
This comment has been hidden.
This comment has been hidden.
Nice and straightforward. On the whole, good job.
What are the snake-case names there for? And why have different cases for different languages? It's just another layer of unnecessary complexity to read through before you can write this ostensibly simple kata. Try to make the description as simple and clear as possible, and cut down on caveats given after the actual information.
Idiomatic names for the resp. language. Haskell uses camelCase, where Ruby and Python use snake case, see PEP8. Either way, the methods could be dropped from the description entirely and their behaviour could get described in comments in the initial code.
@wthit56
The snake-case names are (or rather were) there from when this kata was originaly published in Python (and as @bkaes mentioned above snake-case is the standard for Python)
However considering the fact that there are now more languages and the setup was pretty confusing, I've modified the description so that the methods are displayed in the case for the language the kata is being trained in.
Cheers.
Thanks : )
it would be nice put some reference links for surface_area and volume.
CoffeeScript translation added. Please approve.
Done!
At the moment, I would mark that (JS):
Whoops, forgot to finish my draft. Haskell translation kumited. However, it differs sightly from the Python/JS ones, as Haskell has no classes (in the OOP sense).
Error approving it I'm not sure what the problem is
Merge conflict, since Zozo provided his translation and changed the description. I've resolved it by hand, you should be able to approve the translation now. *edit* that was fast.
Done Thanks
JS translation kumited.
(Description modified) More info on how to approve it ( or not )
Approved
Nice simple kata.
However, for Python, the standard is to use snake_case for method names, not camelCase. Consider renaming methods to
get_height,get_lengthetc. in the Solution Setup (you can provide aliases in the test fixture so that already submitted solutions don't get broken).How do I create aliases?
It's fixed now. Though you will have to redo it.
Just add this to the top of test fixture, and all old solutions will be valid again:
@MMMAAANNN: What about new solutions? Won't the non-existing attribute/method
getWidthlead to problems?You are right, I haven't tested that properly. Here is the corrected code:
Done
Thanks
You might want to change the spelling of dimension in your tests! ;)
oops!