convention

Fluent Nhibernate Automap convention for not-null field

北城以北 提交于 2019-12-01 04:01:36
Could some one help, how would I instruct automap to have not-null for a column? public class Paper : Entity { public Paper() { } [DomainSignature] [NotNull, NotEmpty] public virtual string ReferenceNumber { get; set; } [NotNull] public virtual Int32 SessionWeek { get; set; } } But I am getting the following: <column name="SessionWeek"/> I know it can be done using fluent-map. but i would like to know it in auto-mapping way. Thank you. Also, for reference properties ReferenceConvention need to be done. This is the code that works: public class ColumnNullConvention : IPropertyConvention {

Kotlin Data Class packaging [closed]

一曲冷凌霜 提交于 2019-12-01 02:09:02
问题 Closed . This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post. Closed last year . Kotlin introduces the wonderful concept of Data Classes. These classes will derive the equals()/hashCode() , toString() , getters()/setters() , and a copy() function based on the properties declared in the constructor: data class KotlinUser(val name: String, val age: Int) In

Should I use relative include paths for my project, or place the include-directory on the include path?

天涯浪子 提交于 2019-11-30 11:28:48
In my project, I currently use relative paths to include my files, which admittedly doesn't change often. However, it yields pretty weird include patterns, because I usually nest my files in alot of folders. For example, in my current project I have network/server/myfile.hpp . It needs to include common/log.hpp . Current I use #include "../../common/log.hpp" which is pretty verbose, but works. If i instead add my main include directory on the path, I could simply include "common/log.hpp" . I know this question might be more about preference than anything else, but is there any objective pros

How do I check the equality of three values elegantly?

偶尔善良 提交于 2019-11-30 04:50:39
问题 Say I have values a , b and c . I want to find out if they are equal. If I do if a == b == c{...} Then I get a compile error invalid operation: a == b == c (mismatched types bool and TypeOfABandC) This is pretty obvious, because this parses to: (a == b) == c And (a == b) is a bool. Of course I can do: if a == b && a == c {...} However, this isn't very nice looking and feels confusing. Is there another way? 回答1: A note beforehand: Your last proposed solution is the shortest, clearest and most

Should I use relative include paths for my project, or place the include-directory on the include path?

我只是一个虾纸丫 提交于 2019-11-29 17:08:18
问题 In my project, I currently use relative paths to include my files, which admittedly doesn't change often. However, it yields pretty weird include patterns, because I usually nest my files in alot of folders. For example, in my current project I have network/server/myfile.hpp . It needs to include common/log.hpp . Current I use #include "../../common/log.hpp" which is pretty verbose, but works. If i instead add my main include directory on the path, I could simply include "common/log.hpp" . I

Is It A Bad Practice to List Ruby Version in Both Gemfile and .ruby-version Dotfile?

▼魔方 西西 提交于 2019-11-29 06:06:45
问题 My latest Rails project is more or less and experiment for me to break lots of things and learn in the process. I have the latest version of Ruby specified in my gemfile: ruby '2.2.3' And I also have a .ruby-version dotfile in the project, with the following contents: 2.2.3 Other than the obvious duplication, what is wrong with this? What is the purpose of both conventions? If I should only have one convention for listing my Ruby version, why should I have one (Gemfile) over the other

Java Coding standard / best practices - naming convention for break/continue labels

隐身守侯 提交于 2019-11-29 01:19:08
Sometimes a labeled break or continue can make code a lot more readable. OUTERLOOP: for ( ;/*stuff*/; ) { //...lots of code if ( isEnough() ) break OUTERLOOP; //...more code } I was wondering what the common convention for the labels was. All caps? first cap? If you have to use them use capitals, this draws attention to them and singles them out from being mistakenly interpreted as "Class" names. Drawing attention to them has the additional benefit of catching someone's eye that will come along and refactor your code and remove them. ;) I don't understand where this "don't use labels" rule

How long should SQL email fields be? [duplicate]

余生长醉 提交于 2019-11-28 16:09:06
This question already has an answer here: What is the optimal length for an email address in a database? 8 answers I recognize that an email address can basically be indefinitely long so any size I impose on my varchar email address field is going to be arbitrary. However, I was wondering what the "standard" is? How long do you guys make it? (same question for Name field...) update: Apparently the max length for an email address is 320 (<=64 name part, <= 255 domain). Do you use this? The theoretical limit is really long but do you really need worry about these long Email addresses? If someone

What is better android.R or custom R?

 ̄綄美尐妖づ 提交于 2019-11-28 10:55:28
When I started developping android applications, I had a tendency to define custom R values wherever I need, in particular in layout files. For instance: findViewById(R.id.customerName).setText(customer.getName()) with layout: <TextView android:text="TextView" android:id="@id/customerName" android:layout_height="wrap_content" android:layout_width="fill_parent" /> Now I realize, it might be better to use android.R instead. findViewById(android.R.id.text1).setText(customer.getName()) with layout: <TextView android:text="TextView" android:id="@android:id/text1" android:layout_height="wrap_content

Javabean convention - method naming for property gId

五迷三道 提交于 2019-11-28 05:34:05
问题 If I have a property 'gId' in my Java class what should the accessor method be named as? getGId is what I assume. If there were a property gURL I think it would be getGURL , which kind of looks ugly (not referring to the alternative spelling of girl though). If the property was just url the method name getUrl is good on the eye and yeah I would not name the property as URL in the first place which would make the accessor ugly again - getURL I remember reading from the Javabean Specification