|
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. |
On July 22 2016 01:56 Shield wrote: Verbosity is good as long as it's not abused. You should really read Clean Code before you go further with this discussion.
I did read it. And I still think that "readAllLines" could as well be "getLines" without any detriment to readability...
|
Aren't reallyLongAndAwesomelyDescriptiveMethodNames good sometimes? If it's the most accurate way of describing the use of the function then it isn't unnecessary or useless, even if it's a bit long. Plus with autocomplete, it's not "expensive" for typing to have a longer method name.
|
On July 22 2016 05:20 Birdie wrote: Aren't reallyLongAndAwesomelyDescriptiveMethodNames good sometimes? If it's the most accurate way of describing the use of the function then it isn't unnecessary or useless, even if it's a bit long. Plus with autocomplete, it's not "expensive" for typing to have a longer method name.
Descriptive method name is like first impression from meeting someone. Do you want to impress them or do you want to disgust them? 
On July 22 2016 05:10 Manit0u wrote:Show nested quote +On July 22 2016 01:56 Shield wrote: Verbosity is good as long as it's not abused. You should really read Clean Code before you go further with this discussion. I did read it. And I still think that "readAllLines" could as well be "getLines" without any detriment to readability...
"getLines"? Which lines? If you have N lines (N = 10), how many lines? From 1 to 5? From 1 to 6? From 1 to n? readAllLines is unambigious. There is no confusion at all.
|
|
On July 22 2016 05:20 Birdie wrote: Aren't reallyLongAndAwesomelyDescriptiveMethodNames good sometimes? If it's the most accurate way of describing the use of the function then it isn't unnecessary or useless, even if it's a bit long. Plus with autocomplete, it's not "expensive" for typing to have a longer method name.
In my opinion, if you need a whole sentence to name a method, it's probably the case that the method is way too complex and needs to be re-factored.
EDIT: readAllLines is a perfectly fine name. getAllLines would be fine too, but I don't particularly like getLines for the same reason as the previous poster.
|
On July 22 2016 06:21 Prillan wrote:Show nested quote +On July 22 2016 05:20 Birdie wrote: Aren't reallyLongAndAwesomelyDescriptiveMethodNames good sometimes? If it's the most accurate way of describing the use of the function then it isn't unnecessary or useless, even if it's a bit long. Plus with autocomplete, it's not "expensive" for typing to have a longer method name. In my opinion, if you need a whole sentence to name a method, it's probably the case that the method is way too complex and needs to be re-factored.
What about this one?
deserialiseResultAndRecordInDatabase(Json json) { SomeResult result = SomeResult::deserialise(json); _database.recordResult(result); }
It could be broken down into two separate methods. I agree with that, but it's not a complex method despite long name.
|
|
On July 22 2016 06:41 Nesserev wrote:Clearly, you have never visited the 'Korean Music Discussion' thread. All this talk about Java's (and C#) verbosity, while there are clearly bigger gripes to be had with Java; generics are fundamentally broken, lack of constness, equals() vs. ==, mandatory checked exceptions, horrible APIs, 'package' being the default access modifier, etc.
Broken generics? What do you mean?
|
Hyrule18968 Posts
On July 22 2016 02:36 Doodsmack wrote: Are Microsoft SQL Server skills (including T-SQL obv) valuable and future-secure? no
Good to know, and there will always be MSSQL jobs, but Linux servers are like 98% of the internet
|
On July 22 2016 06:21 Prillan wrote:Show nested quote +On July 22 2016 05:20 Birdie wrote: Aren't reallyLongAndAwesomelyDescriptiveMethodNames good sometimes? If it's the most accurate way of describing the use of the function then it isn't unnecessary or useless, even if it's a bit long. Plus with autocomplete, it's not "expensive" for typing to have a longer method name. In my opinion, if you need a whole sentence to name a method, it's probably the case that the method is way too complex and needs to be re-factored. EDIT: readAllLines is a perfectly fine name. getAllLines would be fine too, but I don't particularly like getLines for the same reason as the previous poster. I like "readAllLines" better than "getAllLines" because in the first case the I/O process is clear (probably with side effects too), and "get" in general is a really vague method prefix. I know it's idiomatic Java, but you could just name the get method "allLines" instead, like we would do in Scala.
On July 22 2016 07:57 Shield wrote:Show nested quote +On July 22 2016 06:41 Nesserev wrote:On July 22 2016 00:00 Manit0u wrote:This thread is the best on TL  Clearly, you have never visited the 'Korean Music Discussion' thread. All this talk about Java's (and C#) verbosity, while there are clearly bigger gripes to be had with Java; generics are fundamentally broken, lack of constness, equals() vs. ==, mandatory checked exceptions, horrible APIs, 'package' being the default access modifier, etc. Broken generics? What do you mean? He probably means that they're just a patchwork solution and not actually designed into the JVM. Fucking casts from Object everywhere :D. Also, at the compiler level, the type system is really restrictive as far as generics go.
|
On July 22 2016 08:21 ZenithM wrote:Show nested quote +On July 22 2016 06:21 Prillan wrote:On July 22 2016 05:20 Birdie wrote: Aren't reallyLongAndAwesomelyDescriptiveMethodNames good sometimes? If it's the most accurate way of describing the use of the function then it isn't unnecessary or useless, even if it's a bit long. Plus with autocomplete, it's not "expensive" for typing to have a longer method name. In my opinion, if you need a whole sentence to name a method, it's probably the case that the method is way too complex and needs to be re-factored. EDIT: readAllLines is a perfectly fine name. getAllLines would be fine too, but I don't particularly like getLines for the same reason as the previous poster. I like "readAllLines" better than "getAllLines" because in the first case the I/O process is clear (probably with side effects too), and "get" in general is a really vague method prefix. I know it's idiomatic Java, but you could just name the get method "allLines" instead, like we would do in Scala.
Well, getLines is from Scala actually 
http://www.scala-lang.org/api/current/index.html#scala.io.Source@getLines():Iterator[String]
Anyway, while I agree that unambiguous names are good, probably if your class/method name is long it's probably too complex or too descriptive (I find that programmers tend to be smart people and can infer quite a lot of information that isn't readily present).
I mean, let's just compare some simple stuff from commonly used applications (a simple controller in a web framework):
Java (Spring):
package hello;
import org.springframework.stereotype.Controller; import org.springframework.ui.Model; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestParam;
@Controller public class GreetingController {
@RequestMapping("/greeting") public String greeting(@RequestParam(value="name", required=false, defaultValue="World") String name, Model model) { model.addAttribute("name", name); return "greeting"; }
}
Ruby (Rails):
class GreetingController < ApplicationController def greeting defaults = {:name => 'World'} params = defaults.merge(params)
@greeting.name = params[:name] end end
Python (Django):
// non-class based views def greeting(request, name='World'): return render_to_response('greeting.html', {'name': request.GET['name']})
// class based views from django.views.generic import View
class GreetingView(View): def get(self, request, name='World'): return render_to_response('greeting.html', {'name': request.GET['name']})
I might be a bit off with Django, haven't done anything in it for a while.
As you can see, it's definitely possible to achieve the same thing without being too verbose and without losing too much clarity on the matter.
The biggest problem that Java's verbosity poses for me is not the fact that it's hard to understand but the fact that there's simply so much more to read, which significantly increases time required to assess the code and its function. I don't know about you but I read code way more often than I write it and making this process harder isn't good for me.
In this regard Ruby is pretty awesome. Just going back to our readAllLines examples:
File.open('my_file.txt').each_line
File.readlines('my_file.txt')
File.foreach('my_file.txt')
All of them will work.
|
On July 22 2016 08:16 tofucake wrote:Show nested quote +On July 22 2016 02:36 Doodsmack wrote: Are Microsoft SQL Server skills (including T-SQL obv) valuable and future-secure? no Good to know, and there will always be MSSQL jobs, but Linux servers are like 98% of the internet
Which is probably why MS SQL is coming to linux.
|
Hyrule18968 Posts
Yeah Microsoft realized they can't compete with php/js/mysql if their shit doesn't work on Linux, which is a big part of why they are open sourcing and porting everything.
|
On July 22 2016 06:41 Nesserev wrote: All this talk about Java's (and C#) verbosity, while there are clearly bigger gripes to be had with Java; generics are fundamentally broken, lack of constness, equals() vs. ==, mandatory checked exceptions, horrible APIs, 'package' being the default access modifier, etc. What is so bad about javas generics? I have much bigger problems with C#'s generics since they dont have the wildcard operator. I often find myself wishing I could write List<?> but that is not as easy as it is in Java. The only problem with Java generics I have is the fact you can not create generic arrays or call .class on generic type parameters (for obvious reasons).
What is the lack of "constness"?
And what is the problem of "equals() vs. =="? Do you mean you have a problem with both having a different meaning in java? Because I dont know why having more options is bad compared to having two ways to do the same thing.
Checked exceptions are not a bad thing either. It is bad that they are used within the JDK, but I am very happy that I can define my own checked exceptions and force myself to use them in my code with a compiler pointing out everytime I missed one.
The package access modifier is shit though. But its a relict of the very first versions of java. Its history and the java people dont ever want to break backwards compatibility (which you can like or dislike but at least they are consistent).
|
On July 22 2016 06:26 Shield wrote:Show nested quote +On July 22 2016 06:21 Prillan wrote:On July 22 2016 05:20 Birdie wrote: Aren't reallyLongAndAwesomelyDescriptiveMethodNames good sometimes? If it's the most accurate way of describing the use of the function then it isn't unnecessary or useless, even if it's a bit long. Plus with autocomplete, it's not "expensive" for typing to have a longer method name. In my opinion, if you need a whole sentence to name a method, it's probably the case that the method is way too complex and needs to be re-factored. What about this one? deserialiseResultAndRecordInDatabase(Json json) { SomeResult result = SomeResult::deserialise(json); _database.recordResult(result); }
It could be broken down into two separate methods. I agree with that, but it's not a complex method despite long name. It's not always true of course, but in this case I don't see the need of an extra function at all. I'd just write
database.record_result(deserialize(data))
or if I had to name it, store_result would be enough.
Anyways, let's not get into too many examples because we could end up doing that forever otherwise, so let me rephrase it.
In my opinion, in general, if you need a whole sentence to name a method, you could probably refactor it or rename it.
I don't think that Java is overly verbose on this, but Swift on the other hand, just wow.
|
Tried to update Apache Camel to newer version, including the dependencies. Upped the versions in pom.xml, mvn clean, mvn install and now the builds fail because fucking spring-test package is using juni4 packages instead of junit38 and every single test fails to compile since 90% of the imports are now obsolete or changed.
I hate my life right now.
|
|
You have the "final" keyword in java which does just that. If a variable is declared final its value will never change. If a class is declared final it can not be extended anymore. If a method is final it can not be overwritten. Its not exactly what you are describing though.
All these things you mention can be done in java with code but are special functions build into the core of the language instead. I can see how some people can like that, but I prefer less keywords and doing things on my own by writing good code. I mean I can see these things being useful, but I never actually needed them myself.
|
On July 22 2016 22:01 RoomOfMush wrote: You have the "final" keyword in java which does just that. If a variable is declared final its value will never change. If a class is declared final it can not be extended anymore. If a method is final it can not be overwritten. Its not exactly what you are describing though.
All these things you mention can be done in java with code but are special functions build into the core of the language instead. I can see how some people can like that, but I prefer less keywords and doing things on my own by writing good code. I mean I can see these things being useful, but I never actually needed them myself.
Final and const are not equivalent at all. Setting a parameter to const says that the function will not change that value. Java's final makes it immutable so it can never be changed. For instance, I could have the following functions:
void printValue(const int value) int addValue(int value)
Consider the situation where I pass value to printValue, addValue, and then printValue again. I can pass my int to each of these functions and const just guarantees that the value won't be changed.
If I made a final int in Java like you suggest then I wouldn't be able to call addValue. Const provides a completely different meaning.
|
|
|
|
|